> One day we were chatting in a group meeting and he said he was working on a TPC-C benchmark that was spending too much time in the SCSI disk driver, so he wrote a 10-line awk script running against kernel memory to look at the SPARC machine code execution path and find which branches were being predicted wrong, then wrote another awk script to flip the branch prediction bits in memory and it showed a significant speedup.<p>SPARC exposed read <i>and write</i> access to branch prediction!? That's... fascinating. Here I thought branch prediction was always a completely opaque thing that the CPU did internally and <i>maybe</i> if you were lucky it might let the program be able to know that it was happening after the fact. Hm... I wonder if it's easier to perform Spectre type attacks if you can just ask the CPU about that kind of behavior? No need to do timing attacks if the CPU will just tell you
We used to have a piece of Java software called Scout - it did a lot of small memory allocations... Led to runtime of multiple days for some datasets. I was reading the book Solaris Internals. The edition I had was updated for the ultrasparc 3's, and I was reading that section that talked about memory pages and the new support for huge pages, eg 4GB pages. We switched on 4GB pages and the week long runs of Scout went to only a few hours. That performance gain was real money and time.<p>That was an interesting trip down memory lane.
To young engineers reading this, note that his early sales experience taught him how to deliver value to customers, not just checkins to git. If someone tries to promote you into sales engineer and you shy away because of wearing a tie or whatever, you are losing out on a huge opportunity to improve your engineering career.
i didn't know what i was expecting when i started to read this but it wasn't that. i didn't know the author before the article but i thought it was really an amazing read. i think it speaks very well to the power of collaboration and a congenial and healthy work environment.<p>as another commenter mentioned the thing about the branch prediction bit flipping in awk was quite something. the SE Toolkit to monitor kernel perf, which could run for <i>years</i> without issue - was something cool too. the guy who found and fixed a kernel bug offering the biggest performance win in Solaris 8 in the course of writing the first book in a series called Solaris Internals - wow. the description of "the can of worms project" in which they run workloads that look like what customers might use, things that that go beyond typical eng team benchmarks, and the meltdown prevention and heading off of customer issues, it's a great concept from my personal point of view. i appreciated the touching on other more human subjects like the capacity planning DB pricing calculator for customers and the bizdev, relationship, and product design points.<p>i started off being jealous of what the guy was saying but i was so blown away by everything that i had forgotten that feeling by the end of the article. it was replaced with awe.
A fun reminder that Sun charged what they damn pleased for hardware and wasted the money on a party culture and a lot of make-work jobs for their pampered staff. This is why Linux won.