Monday, March 31, 2014

I really like Adrián Somá's work, it's so different from what we're used to, and it's very refreshing. He gave a presentation at Smalltalks 2013, of which we posted the video. Now he also provided us two additional versions, one in English and one in Spanish. Enjoy!

Saturday, March 29, 2014

Doing VM work demands that one becomes at least somewhat pedantic, i.e. "a person who is excessively concerned with minor details and rules". Please understand that I am not celebrating unnecessary complexity. However, letting go of a minor detail frequently results in awful VM misbehavior plus weeks to months of debugging and hair loss. After enough of those, one eventually learns the lesson and becomes a pedant by necessity.

Today, I cringe when I hear arguments that start like this:

Well, obviously, everybody knows that...

The above brings me to one of those slam dunk arguments:

Well, obviously, everybody knows that programs run significantly faster when the compiler omits the frame pointer. The performance improvement is because the executable doesn't have to deal with the frame pointer, and the register usually allocated to the frame pointer becomes available for other things.

The above even sounds reasonable, particularly in the case of 32 bit x86 code. Isn't having %ebp free for other things nice? Maybe. Except I was reading the white paper on Windows Error Reporting a while ago, and it has the following paragraph:

The decision to disable frame-pointer omission (FPO), in Windows XP SP2, was originally quite controversial within Microsoft. FPO suppresses the creation of frame pointers on the stack, instead using offsets from the ESP register to access local variables. FPO speeds function calls as frame pointers need not be created on the stack and the EBP register is free for local use. Programmers believed FPO was crucial to performance. However, extensive internal testing across a wide range of both desktop and server benchmarks showed that FPO provided no statistically provable benefit but significantly impaired post-mortem debugging of unexpected call stacks. Ultimately it was decided that the benefit of improving post-mortem debugging outweighed the cost of disabling FPO.

Ouch... so let's try again:

Well, obviously, everybody knows that programs might run significantly faster when the compiler omits the frame pointer. The performance improvement iscould occur because the executable doesn't have to deal with the frame pointer, and
the register usually allocated to the frame pointer becomes available
for other things. Your mileage may vary.

The assertion doesn't sound as authoritative, which may be disappointing to some. More importantly, though, the claim is closer to reality.

Friday, March 07, 2014

During my tenure at Cincom, HPS (the Cincom Smalltalk VM) went from a peak of ~359.5k LOC, to ~233.5k LOC as of a couple days ago. This loss of ~126k LOC represents 35% of the source code base from seven years ago. As per my presentation at Smalltalks 2013, HPS has not been this small since the early 90s --- this, while being markedly faster and having significant new features.