A 40-line fix eliminated a 400x performance gap
1–10 of 81 posts
Re: A 40-line fix eliminated a 400x performance gap
#2Author here. After my last post about kernel bugs, I spent some time looking at how the JVM reports its own thread activity. It turns out that "What is the CPU time of this thread?" is/was a much more expensive question than it should be.
Re: A 40-line fix eliminated a 400x performance gap
#3Author here. After my last post about kernel bugs, I spent some time looking at how the JVM reports its own thread activity. It turns out that "What is the CPU time of this thread?" is/was a much more expensive question than it should be.
Did you look into the large spread on your distributions? Some of these span multiple orders of magnitude which is interesting
Re: A 40-line fix eliminated a 400x performance gap
#4Author here. After my last post about kernel bugs, I spent some time looking at how the JVM reports its own thread activity. It turns out that "What is the CPU time of this thread?" is/was a much more expensive question than it should be.
Did you look into the large spread on your distributions? Some of these span multiple orders of magnitude which is interesting
Fair point. These were run on a standard dev workstation under load, which may account for the noise. I haven't done a deep dive into the outliers yet, but the distribution definitely warrants a more isolated look.
Re: A 40-line fix eliminated a 400x performance gap
#5This is such a great writeup
Re: A 40-line fix eliminated a 400x performance gap
#6Author here. After my last post about kernel bugs, I spent some time looking at how the JVM reports its own thread activity. It turns out that "What is the CPU time of this thread?" is/was a much more expensive question than it should be.
I don't think it is possible to talk about fractions of nanoseconds without having an extremely good idea of the stability and accuracy of your clock. At best I think you could claim there is some kind of reduction but it is super hard to make such claims in the absolute without doing a massive amount of prep work to ensure that the measured times themselves are indeed accurate. You could be off by a large fraction and never know the difference. So unless there is a hidden atomic clock involved somewhere in these measurements I think they should be qualified somehow.
Re: A 40-line fix eliminated a 400x performance gap
#7Author here. After my last post about kernel bugs, I spent some time looking at how the JVM reports its own thread activity. It turns out that "What is the CPU time of this thread?" is/was a much more expensive question than it should be.
I don't think it is possible to talk about fractions of nanoseconds without having an extremely good idea of the stability and accuracy of your clock. At best I think you could claim there is some kind of reduction but it is super hard to make such claims in the absolute without doing a massive amount of prep work to ensure that the measured times themselves are indeed accurate. You could be off by a large fraction a…
Stability and accuracy, when applied to clocks, are generally about dynamic range, i.e. how good is the scale with which you are measuring time. So if you're talking about nanoseconds across a long time period, seconds or longer, then yeah, you probably should care about your clock. But when you're measuring nanoseconds out of a millisecond or microsecond, it really doesn't matter that much and you're going to be OK with the average crystal oscillator in a PC. (and if you're measuring a 10% difference like in the article, you're going to be fine with a mechanical clock as your reference if you can do the operation a billion times in a row).
Re: A 40-line fix eliminated a 400x performance gap
#8Author here. After my last post about kernel bugs, I spent some time looking at how the JVM reports its own thread activity. It turns out that "What is the CPU time of this thread?" is/was a much more expensive question than it should be.
Very thankful for the 1liner tldr
edit : I had an afterthought about this because it ended up being a low quality comment ;
Bringing up such TLDR give a lot of value to reading content, especially on HN, as it provides way more inertia and let focus on -
reading this short form felt like that cool friend who gave you a heads up.
Re: A 40-line fix eliminated a 400x performance gap
#9Author here. After my last post about kernel bugs, I spent some time looking at how the JVM reports its own thread activity. It turns out that "What is the CPU time of this thread?" is/was a much more expensive question than it should be.
Very thankful for the 1liner tldr edit : I had an afterthought about this because it ended up being a low quality comment ; Bringing up such TLDR give a lot of value to reading content, especially on HN, as it provides way more inertia and let focus on - reading this short form felt like that cool friend who gave you a heads up.
I was unsure whether to post it or not so I am glad you found it useful!
Re: A 40-line fix eliminated a 400x performance gap
#10Earlier quoted context omitted.
Very thankful for the 1liner tldr edit : I had an afterthought about this because it ended up being a low quality comment ; Bringing up such TLDR give a lot of value to reading content, especially on HN, as it provides way more inertia and let focus on - reading this short form felt like that cool friend who gave you a heads up.
I was unsure whether to post it or not so I am glad you found it useful!
I have that 10-30s time window to fill when claude might be loading some stuff ; the 1 liner is exactly what fits in that window - it makes me wonder about the original idea of twitter now that I think of it - but since it's not the same kind of content I don't bother with it.It really feels like "here is the stuff, here's more about it if you want to" - really really appreciate that form and will definitely do the same format myself