Saturday, August 23, 2014

While at the Seaside Sprint...

Philippe Marschall had an interesting problem to think about... suppose you have a dictionary with string keys, and that you make sure the keys are uppercase.  Alas, when the code receives queries, it gets lowercase keys.  Fixing this requires sending asUppercase, which takes time.  Can you find a way such that both at: and at:put: can be made to work without sending asUppercase?  Can you do it without creating new classes?

I got a proof of concept to run 2x faster.  From what I hear, the improved code will help speed up HTTP requests.

Exceptions fixed in Squeak, Pharo and Cuis

Martin McClure just integrated the Pharo exceptions fix we worked on during Camp Smalltalk.  I imagine this fix, in 5 slices, should be straightforward to port to Squeak and Cuis.

Update: I ported the Pharo fix to Cuis.

About ESUG 2014

What a lovely conference, I'm glad to be back.  I really enjoyed the talks, you should go to the YouTube playlist and take a look.  Some that come to mind are Eliot Miranda's Spur talk, Clement Bera's talks about adaptive optimization, Tim Rowledge's talk on his work on Scratch, and Boris Shingarov's talk about modern problems for the Smalltalk VM in the IWST track, as well as Yuriy Tymchuk's presentation on Smalldromeda and Alexandre Bergel's Roassal presentation.  This is hardly a fair list though, so please excuse my brevity in favor of ESUG's video playlist.

I am also glad my Retrospective presentation was well received.  The results earned compliments from Tudor Girba.  There were plenty of laughs during the talk, and it was a lot of fun :).

More news to come...

Monday, August 11, 2014

3x+1 over the weekend

You will recall from my previous 3x+1 posts that using

T^n(q2^n + r) = q3^j + T^n(r)

one could build an evaluation matrix for each 0 <= r < 2^n.  For a long time, I had strong circumstantial evidence that the proportion of evaluation matrix rows satisfying T^n(k) > k tended to shrink as n grew.  It's so unsatisfying to merely feel something has to be true...

I am happy now, though.  After reading Concrete Mathematics for several hours, I managed a tentative proof showing the proportion of rows satisfying the growth inequality tends to zero as n goes to infinity.  If you are interested, send me a note --- there is no way I am typesetting that heavy math in this blog post!

Friday, May 30, 2014

Do you know this card game?

My grade school graduation trip was to the lovely Argentine province of Córdoba.  On the last day, we were waiting to get on the bus back to Buenos Aires, and I noted a couple playing a card game in the hotel's galeria.  I watched them play for a while but didn't recognize the game, so I asked them about it.  The couple explained they were playing a game called Desesperación (Desperation), and taught me the rules in a few minutes.  Soon after, we had to leave.  I'm glad I asked when I had a chance, because now I can't find references to the game nor the rules...

Anyway, perhaps you know the game with a different name?  Here's how 2 players play.  Take two poker decks, shuffle, and make a 20-card pile for each player (the pile size can vary, see more below).  The top pile card faces up, the others face down.  Any remaining cards become the drawing pile.  The goal of the game is to play all the cards in one's pile first.  A playing turn goes like this:

1.  Draw enough cards from the drawing pile to hold 5 cards.

2.  Any aces must be played to the aces section (which at first is empty).  In addition to aces held in hand, aces on top of a player's pile also have to be played.

When a pile's top card is played, the next card is flipped so it's facing up.  If an ace comes up, it also has to be played.

3.  Now a player can play onto ace piles by number sequence from 2 to K (color and suit don't matter).  When an ace pile reaches K, it is placed on a temporary recycling pile.  When the drawing pile is exhausted, the recycling pile is shuffled and becomes the new drawing pile.

Held cards can also be played onto 3 staging columns growing towards each player.  Column cards can only be played onto aces, and only the bottom card of a column can be played.  The idea is to use held cards and the staging columns to help play the pile cards.  However, columns cannot be rearranged.  Note the tension between wanting to play all "useless" cards onto the columns (to draw 5 cards in the next turn), and wanting to keep columns in reasonably playable (staggered) order.  Properly managing the staging columns is critical to winning the game.

In summary, held cards can be played onto aces or staging columns, while cards in columns and player piles can only be played onto ace piles.

Jokers can substitute for any card, including aces.

4.  If a player plays all 5 cards onto the aces section, the player can draw 5 more cards and keep playing.  Otherwise, it's the next player's turn.

It's common to get in a rut and repeatedly fail to get the card combination needed to play pile cards, hence the name of the game.  Desesperación scales to N players given a reasonable number of decks and sensible pile sizes.  Larger piles tend to make certain cards scarce, and as a result the game becomes more challenging and interesting.  However, keep in mind that excessively large piles (e.g. 40 card piles for 2 players with 2 decks), the game will get stuck due to unavailable cards.

Monday, May 12, 2014

New take on Mussorgsky's Pictures at an Exhibition

I saw a modern jazz adaptation of Mussorgsky's Pictures at an Exhition last Monday with just the jazz trio, and again yesterday with the full orchestra set.  In both cases, it was performed and conducted by the composer Yaron Gottfried.  It is really, really good music.

Also, thank you Модест Петрович Мусоргский.

Monday, March 31, 2014

New versions of Smalltalks 2013 presentation

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

About omitting the frame pointer

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 is could 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.

Monday, March 17, 2014

Important news (part 2)

So, today was my first day at LabWare.  LabWare makes leading laboratory management software, and I will be doing Smalltalk VM work.  The future looks really interesting, now it is time to go invent it.

Friday, March 07, 2014

Last HPS source code size status

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.