Interesting take. Will it lead to paying more attention to performance in software? Will it be the rise of the specialized CPUs? Time will tell.
Good explanation of how flame graphs are produced and how to read them. Gives a few tips on what to look for to optimize.
Interesting exploration on the performance of SSDs regarding write patterns. Turns out sequential IO is still a thing, just for a different reason than with good old HDDs.
Very interesting to see that move to owned hardware... turns out that not only the invoice is smaller in their case but the performances are much better as well.
Nice set of tips, I knew a few but not all of them. The discussion around CTEs is interesting.
Nice exploration of false sharing on performances in several hardware scenarii. A couple of surprises along the way.
Shouldn't come as a surprise if you paid attention to C++ evolutions for the past 30 years. We're now reaping the fruits though, so it's really become easy to keep both options in sight when designing. This is especially important for performance sensitive code.
Nothing really new here (apart from the "how easy it is these days!")... Still it needs to be reminded on a regular basis. :-)
Nice post explaining the common algorithms used for load balancing. Each having their own trade offs of course. Well done with tiny simulations.
Polars really looks like a nice alternative to Pandas with a nice upgrade path from data exploration to production.
Nice walk through for a use of PyO3 to make some Python code much faster. Nice to see how useful py-spy turn out to be in such scenarii as well.
Very interesting conversation between Uncle Bob and one of the recent critics of his work regarding performance. I like how he admits some faults in the way he presents things and try to improve for later rather than trying to be right. Some people should learn from that. There's clearly a tension between performance and what is described in Clean Code, it'd be pointless to deny it.
perf now available also to Python programs. This definitely can be useful for proper profiling.
Interesting position from AMD regarding the race on the next super computers. They're all being caught up by energy efficiency so it'll need to be addressed both at the processor architecture level but also at the software architecture level. How we design our computing tasks will matter more and more.
A bit of a sarcastic tone but a few good point in there. Also shows interesting alternatives to C++ to squeeze every ounce of performance out of your code whatever the platform it runs on. Of the three options explored I knew only about Numba really.
Excellent analysis and explanation of the stutter problem people experience with game engines. It's an artifact of the graphics pipeline becoming more asynchronous with no way to know when something is really displayed. Extra graphics APIs will be needed to solve this for real.
Time to look a bit at the maze of WebAssembly runtimes. Good overview on how they currently perform and how well they are documented or easy to use.
Python is getting faster but is still far from what you can get with C++ of course. That said, for simulations you likely don't want everything in Python or in C++. Part of the challenge is to split the subsystems properly and use C++ where it matters.
Don't underestimate performance of the generated code when a JIT is in the picture. Very good example with the JVM just there.
Don't bank it all on faster hardware, make sure your software isn't slow first. Otherwise it'll bring quite some hidden costs.
Little simple benchmark of WebAssembly performances for the most common languages found there. Careful to the payload size though.