macOS Is Swift getting slower?

[Flaming Gerbil]

I learned Swift a few years back and created a few simple iOS, MacOS apps, and also did some hybrid C++/Obj C/Swift coding using Djinni.

Coding is more of a sideline / hobby for me, and I tend to be project-focused rather than wedded to a single language / platform.

At the time I was coding in Swift, the debian.net benchmarks game site was showing Swift, compared to other compiled languages, as middle-of-the-pack or slightly better in speed, beating out Java and C#.

I'm currently learning C# / Ninjascript and decided to see how C# compares to Swift now. I was surprised to find the most current results from the site have Swift at the bottom of the pack, behind all the listed compiled languages, including C#.

Here's the link: Benchmarks Game.

Wondering if anyone has insight into why this is?

Is it that Java and C# have improved a lot in speed, or is Swift just getting bogged down with feature bloat?

On a side note, they're also showing C++ beating C; previously the reverse was true.

 

[Senor Cuete]

A big reason that Swift was invented is that somebody at Apple made stupid mistakes while programming with C. Swift was designed as a nanny language that would protect programmers from themselves. Swift does things like check for integer overflow every time you add integers and check to see if you used an out of bounds index in an array when you use arrays. There is significant overhead in doing this.

I've seen the site you mention. There are a lot of useful speed tests on that site. Here's another example of how bad some languages are for some tasks:

Moore's Law is deader than corduroy bell bottoms. But with a bit of smart coding it's not the end of the road

Don't aim for the bottom, go top down

www.theregister.com

The comments on that article are interesting. Somebody commented that the SEVEN HOUR time with python took his Mac 0.1 second with Xcode and C.

Interpreted languages are hopeless. People have been telling me for decades that machines are so fast now that you can use crappy languages anyway. Yeah, right. Object oriented languages are good for programming GUIs using frameworks but they have to manage their object trees and do garbage collection. This takes time. C is so fast because it doesn't do things like this. A good reason to know how to program in C is that it may be required for high-performance computing. If you are a C++ programmer you can write computation-intensive tasks in C.

 

[casperes1996]

A big reason that Swift was invented is that somebody at Apple made stupid mistakes while programming with C. Swift was designed as a nanny language that would protect programmers from themselves. Swift does things like check for integer overflow every time you add integers and check to see if you used an out of bounds index in an array when you use arrays. There is significant overhead in doing this.

I've seen the site you mention. There are a lot of useful speed tests on that site. Here's another example of how bad some languages are for some tasks:

Moore's Law is deader than corduroy bell bottoms. But with a bit of smart coding it's not the end of the road

Don't aim for the bottom, go top down

www.theregister.com

The comments on that article are interesting. Somebody commented that the SEVEN HOUR time with python took his Mac 0.1 second with Xcode and C.

Interpreted languages are hopeless. People have been telling me for decades that machines are so fast now that you can use crappy languages anyway. Yeah, right. Object oriented languages are good for programming GUIs using frameworks but they have to manage their object trees and do garbage collection. This takes time. C is so fast because it doesn't do things like this. A good reason to know how to program in C is that it may be required for high-performance computing. If you are a C++ programmer you can write computation-intensive tasks in C.

Hm. So first of all I'd like to note that a lot of Swift's safety features can be turned off, and for example for unwrapping, instead of using the ! operator, you can use .unsafelyUnwrap() which won't check the validity of the unwrap.

Swift and its runtime have definitely gotten faster and smaller since its inception.

Mostly I'd say comparisons across languages are inherently a little flawed for one simple reason.
How do you code in each language? Do you just straight up write it as similar to your baseline language as possible or do you try and follow the conventions of the language you're writing in?

And OO languages do not *need* to do garbage collection. C++ has classes and objects and you manually destroy your objects when you're done with them. - Though there is actually support for GC with C++ as well

 

[igouy]

At the time I was coding in Swift, the debian.net benchmarks game site was showing Swift, compared to other compiled languages, as middle-of-the-pack or slightly better in speed, beating out Java and C#.

Look more closely — Swift versus Java fastest programs

In retrospect wrongly Swift was allowed not to use ARC for binary-trees and use Apache Pools instead. Now the Swift program does use ARC for binary-trees.

On a side note, they're also showing C++ beating C; previously the reverse was true.

There's little difference between the handful of tiny programs, so the C programs and C++ programs have been swapping around for a couple of years. And then the hardware changed.

 

[igouy]

Hm. So first of all I'd like to note that a lot of Swift's safety features can be turned off…

The source code for all the programs shown on that website is shown, so you can see whether or not Swift's safety features were turned off.

Mostly I'd say comparisons across languages are inherently a little flawed for one simple reason.
How do you code in each language? Do you just straight up write it as similar to your baseline language as possible or do you try and follow the conventions of the language you're writing in?

Something intermediate between chaos and rigidity.

 

[casperes1996]

The source code for all the programs shown on that website is shown, so you can see whether or not Swift's safety features were turned off.




Something intermediate between chaos and rigidity.

Sure - It was documented and that's great. But my point was it could be done in different equivalent functionally equivalent ways. The testing methodology may be good; I just meant that there isn't a perfect testing methodology for this stuff

 

[igouy]

But my point was it could be done in different equivalent functionally equivalent ways. … I just meant that there isn't a perfect testing methodology for this stuff

More — the website allows the programs to "be done in different equivalent functionally equivalent ways".

There may be "a perfect testing methodology" ("a single best technique") but that depends on the context (the goal of the study).

 

[Senor Cuete]

If you are a C++ programmer you can write computation-intensive tasks in C.

One of the stupid things Bjarne Stroustrup did when he invented C++ was to change operator precedence so when you port C to C++ and visa versa you have to be very careful to be sure that operations will happen in the correct order. This is usually accomplished by using a lot of parentheses.

 

[casperes1996]

One of the stupid things Bjarne Stroustrup did when he invented C++ was to change operator precedence so when you port C to C++ and visa versa you have to be very careful to be sure that operations will happen in the correct order. This is usually accomplished by using a lot of parentheses.

I've only written very, very limited C; What operator precedence is different? Don't both follow normal mathematical rules?

 

[Senor Cuete]

Operators in C and C++ - Wikipedia

en.wikipedia.org

 

[TiggrToo]

The comments on that article are interesting. Somebody commented that the SEVEN HOUR time with python took his Mac 0.1 second with Xcode and C.

Way to go on missing the point of the article.

The underlying point being made wasn’t about programming languages per se, but that CPUs need to be rethought with smaller chipset instruction sets and more cores, and that most applications need to be rewritten to take advantage of that.