Victor Zverovich

> Int to string is especially egregious because it requires a lot of division which is basically the slowest (common) thing you can do on a CPU. Yeah. There's some great benchmarking and tips: https://www.zverovich.net/2013/09/07/integer-to-string-conversion-in-c… Godbolt example: https://godbolt.org/z/M4b353PKv of which the meat is imul rcx, rcx, 1374389535 shr rcx, 37 imul edi, ecx, 100 mov r8d, edx sub r8d, edi movzx edi, WORD PTR .LC2[r8+r8] mov WORD PTR [rsi], di So if our example input is 12345, the first two instructions use the field-inverse property to compute "123" with multiply rather than divide (1 clock, latency 4), then multiply up again to get "12300", then subtract that to get "45". That can then be looked up at position 45+45 in the string "00010203040506070809101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899" to give you the two digits.

{fmt} has internal buffering but it's not yet exposed to users. There is a feature request for it: https://github.com/fmtlib/fmt/issues/2354. FILE buffering is not too bad but it can be easily optimized: https://www.zverovich.net/2020/08/04/optimal-file-buffer-size.html.

CircleCI offers build caching that works well enough, for example. It's not the super advanced stuff that Bazel can do, but you don't need Bazel to do build caching. When the Linux kernel (~27 million LoC) can be compiled from scratch in under a minute on modern machines (30 seconds on some of the beefier machines)... there's clearly a lot of low-hanging fruit in that "hours long" compilation that has nothing to do with build caching. Whether you can get stakeholders to buy into paying down technical debt or not is an unrelated discussion. Sometimes it's easier to sell fancier build systems as the solution instead of better code organization and simplifying overly generic code. C++ code doesn't have to be super slow to compile: https://www.zverovich.net/2017/12/09/improving-compile-times.html

> Which raises the obvious questions: why didn't C++11 implement template printf along with variadic templates? https://en.cppreference.com/w/cpp/utility/format and the actual proposal https://www.zverovich.net/2019/07/23/std-format-cpp20.html

Well, it's been 4 years so maybe it's better now: https://www.zverovich.net/2016/05/13/giving-up-on-julia.html Well, running "Hello, World" still takes 0.3 ms :D

Where are we compared to then (http://www.zverovich.net/2016/05/13/giving-up-on-julia.html)?

The link to that article is below. printf in C tranlates to a few lines of assembly in preparation for a call to sprintf. That in turn will have a lot more instructions in assembler. http://zverovich.net/2016/05/13/giving-up-on-julia.html

Honest question, just how fast is Julia anyway? Because performance is typically the main reason anyone would want to use it over alternatives. A lot of people justify Julia because, as noted in other comments, it is both high-level yet claims to be nearly as fast as C: > "Julia is the fastest modern open-source language for data science, machine learning and scientific computing...with the speed, capacity and performance of C, C++..." [4] That's a bold claim! And there is much evidence to the contrary. I often find that the language falls into a similar trap of many other languages where the creators are evangelists not quite sharing the whole picture. Writing fast Julia code is not always a pleasant experience as you often need to fight the easier idioms. It is marketed as fast, but really, how fast is it? [0] http://www.zverovich.net/2016/05/13/giving-up-on-julia.html "What’s disappointing is the striking difference between the claimed performance and the observed one. For example, a trivial hello world program in Julia runs ~27x slower than Python’s version and ~187x slower than the one in C." [1] https://www.ibm.com/developerworks/community/blogs/jfp/entry/A_Compari… "We can code in Julia in a way similar to Python's code. However, that code is slower than it should. One way to speed Julia is to take into account the Fortran ordering it uses by looping on j before looping on i in the…