FreePascal comes top in simple string benchmark!!

[vfclists]

I just came across the simple language comparison with has FreePascal coming top in performance, and wonder what has been happening in my "absence" from Lazarus.

https://www.youtube.com/watch?v=f-Xma1un1Fs&t=1418s

Or is it simply a case of FreePascal being optimized for string handling?

[domasz]

wonder what has been happening

Beatings, lots and lots of dev guys beatings.

[Handoko]

Good to know Free Pascal is fast. But I wonder why he didn't include C/C++ in the test.

[runewalsh]

Pascal version cheats because all (?) of the other versions do the actual split by lines/words. The author was lucky to find a built-in, zero-allocation StrUtils.WordCount, but more direct equivalent to other versions (like Length(Contents.Split([#13, #10])) using TStringHelper methods) would probably be abysmal, and conversely, possible re-implementations of WordCount could make other languages comparable or better.

(On my computer, StrUtils.WordCount(scanner.pas contents) takes 620 mcs and Length((scanner.pas contents).Split([#32, #9, #10, #11, #12, #13], TStringSplitOptions.ExcludeEmpty)) takes 3.2 ms, so “only” 5× slower though.)

[Eugene Loza]

Pascal version cheats

Don't all benchmarks cheat? I mean the same code may be written in many different ways, some better some worse. What I usually see (and I don't see much, so maybe exaggerating) is that often in benchmarks people write optimized code in C or other language and literally bruteforcing the problem in Pascal eventually giving the summary that Pascal is bad, almost feels like on purpose And if once for a lifetime Pascal code did the same thing (maybe unaware of other more efficient solutions in other languages) - it's to be frowned upon

The longer I code, the more I feel like "benchmarks" don't really mean a lot. If one needs to impress a benchmark - write in Assembly (Pascal allows that too!), you can't possibly get a higher optimization cap. But in real program scenario the performance very little depends on the language used (ok, closing eyes at Garbage Collectors) but rather on how the program is implemented. And in current world state developers usually care more about how long it would take to develop a program (which determines the cost of the program), than how efficiently it will execute - it should only be "efficient enough" to provide convenient workflow for the end users.

[TRon]

The longer I code, the more I feel like "benchmarks" don't really mean a lot. If one needs to impress a benchmark - write in Assembly (Pascal allows that too!), you can't possibly get a higher optimization cap.

The real benchmark for me is the benchmark where I start from scratch and have a full working application that does as intended in about an hour or two (given that the assignment is not too complex. Where are those benchmarks ? Does any other programming language have a full fledged IDE that let me do that ? If not then there is no competition and "Pascal" always wins. In the end all that matters in the real world is how quickly you can create and deploy your applications.

[vfclists]

Good to know Free Pascal is fast. But I wonder why he didn't include C/C++ in the test.

I don't think C/C++ is the kind of language the author would want to use in the test.

The focus is on languages easy to get going with, and Oh those C++ compile times.

It shows how despite being a compiled language, FreePascal can be competitive with so called dynamic languages in terms of the speed of getting programs up and running.

[Rochus]

As far as I understood from the video the benchmark just consists of "utf-8 char counting" of a 4MB text file. Not particularly representative as a benchmark at all. I would say nothing at all can be concluded from this concerning performance of the code generated by the compiler. That said FP generates pretty fast code (about 65% of the performance of g++ generated code, see https://forum.lazarus.freepascal.org/index.php/topic,64261.0.html).

[440bx]

There is one thing that benchmark seems quite useful at, which is showing the runaway executable sizes created by some (maybe even most) programming languages.

The author praises Nim for producing a "small" executable, around 110K, for a word counting program.  In a normal world, a 110K program should do more than just count words (early versions of Turbo Pascal were a good bit smaller than that.)

It's like seeing "fast" trucks in a Formula 1 race... (gotta love the low center of gravity )