It's a single implementation, I wouldn't put too much on it. I can definitely write a C++ implementation that's slower and less optimised than most of those results, particularly if I was using Boost.

iPhone and Mac apps run pretty well in my experience, and Swift is definitely faster (in general) than Python at least. There were some serious considerations to port over ML libraries to Swift due to its ease of use, similar to Python, while providing much better execution speed.

> There were some serious considerations to port over ML libraries to Swift due to its ease of use, similar to Python, while providing much better execution speed. Google abandoned that Swift work (if that's what you're referring to)

Google and abandoning things, name a more iconic duo

Sure, but the fact that it was a project at all does imply Swift had a not-insignificant speedup vs Python, meanwhile in these benchmarks Python is about2x the speed of Swift.

Note that only an unoptimized Swift solution was provided, and Swift String operations (like `lowercased`) are fully Unicode-compliant.

I only skimmed the article, but I suspect they are including the time necessary to spin up the executable and any runtime environment prior to executing the relevant code.

"Lightning fast" can mean a lot of things, and it might not mean "executables start quickly."

If that were the case, that makes Java's results fairly impressive, given the JVM's slow start time.

Maybe for tiny tiny programs "the JVM's slow start time" is only a few tenths of a second?

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

If that is the case, it would explain why python is so slow. In my experience the runtime speed of python is good enough for most purposes, but startup time is definitely slow.

Swift executables start fairly quickly.

I don't know that I'd characterise it as a "screw up" based on one random person's solution to one particular problem.

In particular the "simple" solutions, which is all that's offered for Swift, will be whatever was most idiomatic/ obvious to a programmer of potentially quite variable quality.

It's unfortunate, I think, that there are "simple" solutions for some languages which have had performance revisions. If you needed an hour, or a friend, or even a community to "hint" how to improve it that wasn't the simple solution.

[ For example I feel like the Rust might be faster asking for ASCII lowercase, and using the unstable (not order-preserving) sort algorithm, but even if I'm correct such a change would logically be made to the optimised Rust, not the simple ]

Swift is in the same or better performance bracket then C#/Java and unsafe usage can be close to performance of C (maybe 1.3-2x slower). I'm not sure about ranting for poor single test results :P

No need for hand-waving, there are publicly available benchmark results: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

It's not the only benchmark in town and it needs to be taken with a grain of salt, but so does every benchmark.

Latner himself (creator of Swift) said Swift had speed issues because of ARC that they were hoping to solve with better code analysis. Did they?

They have been improving this steadily (I would argue it is rarely an issue nowadays, and there have always been simple workarounds), but there’s no reason a solution to the problem mentioned in the article should need to use ARC, and should use structs/protocols instead (which don’t use reference counting). I’ve seen a lot of Benchmarks that rate Swift poorly because of this.

The optimized version of C# is not really optimized as there are things left in the table that could be much close to C++.

>even Pascal and Forth.

Even?

Pascal is touted as being as fast as C

Perhaps bad phrasing on my part. I meant that in the are-they-still-even-maintaining-modern-optimizing-compilers-for-Pascal-and-Forth sense.

FreePascal maintains their own optimizer. It is one of the few languages that still have their own optimizer rather than using LLVM. Although they would probably better of using LLVM. They introduce a new optimization every month, and I usually notice the new optimization when my code starts crashing with the nightly compiler.´

But they have a bunch of reasons why they cannot use LLVM like "LLVM will almost certainly never support all targets that FPC supports (Gameboy Advance, OS/2, WinCE, ...), or at some point drop support for targets that FPC still supports (as already happened with Mac OS X for PowerPC/PowerPC64)." [1]

Or "FPC's native code generators are much faster than LLVM's (even if you would neglect the overhead of FPC generating bitcode and the LLVM tool chain reading it back in), so especially while developing it may be more interesting to use FPC's own code generators"

But the test of this thread mostly benchmarks the hashmap implementation. I got my own Pascal hash map, it is twice as fast than the one in their standard library.

And, looking at the test code, it does a double hashing, first a get, then an insert. If it did a find entry and update it in-place, it would be twice as fast, too.

Together that would be four times faster and as fast as the C version and still be simple

[1] https://wiki.freepascal.org/LLVM#Frequently_Asked_Questions