For me, avoiding heap, or rather avoiding gc came when I was working (at work) on backend and web server using Java, and there was default rule for our code that if gc takes more than 1% (I don't remember the exact value) then the server gets restarted.
Coming (back then) from C/C++ gamedev - I was puzzled, then I understood the mantra - it's better for the process to die fast, instead of being pegged by GC and not answering to the client.
Then we started looking what made it use GC so much.
I guess it might be similar to Go - in the past I've seen some projects using a "baloon" - to circumvent Go's GC heuristic - e.g. if you blow this dummy baloon that takes half of your memory GC might not kick so much... Something like this... Then again obviously bad solution long term
Scala 2's syntax is mostly Java/C-style with a few peculiarities.
Scala 3's optionally allows indentation based, brace-less syntax. Much closer to the ML family or Python, depending on how you look at it. It does indeed look better, but brings its share of issues.[1] Worse, a lot of people in the community, whether they like it or not, think this was an unnecessary distraction on top of the challenges for the entire ecosystem (libraries, tooling, ...) after Scala 3.0 was released.
My personal take is this would be like JavaScript adopting an optional Coffeescript[1] syntax. It's so different that it seems odd to make it an option vs a new language, etc.
Benchmarking requires a bit of different setup than the rest of the testing, especially if you want down to the ms timings.
We have continous benchmarking of one of our tools, it's written in C++, and to get "same" results everytime we launch it on the same machine. This is far from ideal, but otherwise there be either noisy neighbours, pesky host (if it's vm), etc. etc.
One idea that we thought was what if we can run the same test on the same machine several times, and check older/newer code (or ideally through switches), and this could work for some codepaths, but not for really continous checkins.
Just wondering what folks do. I can assume what, but there is always something hidden, not well known.
I agree for measuring latency differences you want similar setups. However, by running two versions of the app concurrently on the same machine they both get impacted more or less the same by noisy neighbours. Moreover, by inspecting the flamegraph you can, manually, see these large shifts of time allocation quickly. For automatic comparison you can of course use the raw data.
In addition you can look at total cpu seconds used, memory allocation on kernel level, and specifically for the jvm at the GC metrics and allocation rate. If these numbers change significantly then you know you need to have a look.
We do run this benchmark comparison in most nightly builds and find regressions this way.
Yes, that can help with detecting how much cpu was actually used during the run. But it doesn’t influence benchmark results. Not sure how exactly to use it for doing subsequent runs and comparing final performance. Then this needs to be extrapolated to final performance in production.
Yeah, what you want to know is which change caused the slowdown, or maybe improved the performance and reasonable metric behind it (for example frame-rate for a game, or something like this).
Lua, by virtue of being thread oblivious - may work, but under the curtain (calling "C" code) there is nothing to protect you against thread-safety related issues.
Python "deals" with it
All three options though are full blown Turing-complete languages - e.g. they can loop forever. You don't want that in CI, or a build system.
Starlark is concurrency safe. Top-level global values, once initialized, are frozen (read-only), hence they can be safely accessed by multiple threads. There are no "global" effects (AFAIK), apart from actually doing I/O by calling actions (processes, etc.)
Blaze (bazel's parent) used Python, and had these non-hermetic issues, because you can do anything with Python (actually "Lua" might be easier to sandbox, but maybe python too - not sure).
Point is, starlark is well suited for this job. It wasn't - "Hey let's design this new language". It's really Python but with limited powers for a reason, to enable other unlimited powers (concurrency, avoid recursion, etc).
Is there a niche "endian" humor about this :) - e.g. is this the little endian, or big endian, or "middle" endian of "Rock Paper Scissors" - excuse my really poor attempt at this.
My grandfather, was a chess-meister, not of huge proportions, but well known in our city. Chess was almost like a diseases (he did not taught my father and his brother in the game, knowing the pain and suffering this would bring later in life)... So one thing he did when he was back home from the local chess club, is to play against himself - replaying old moves, or by the book, or something new, just heard. He would also this with other games - like bridge (or similar). He was truly a genius in his own, and I'm sure he had good time, but he understood really well that it was not good habit long term.
Some people find comfort this way, sometimes it's the only way to get through
reply