Thursday, March 29, 2007

Goodbye ISP!

Ah, how sad. I am about to shut down the FTP server. This internet service has been the best I've experienced in all my time here.

  • Truly no limits.
  • Symmetric 10mbps/10mbps, or as fast as the ethernet wire will take it.
  • Fixed IP addresses.
  • And 24x7 real person technical service.
Alas... now, for the same money, I am going to get 10mbps/768kbps with unknown limits, dynamic IP addresses, and who knows what kind of technical service. It's so unfair...

Newport Telecommunications, you will be missed.

Smalltalk Solutions 2007 events coming up!

Our first event for Smalltalk Solutions 2007 has just been announced. Boris Popov started a reservation for the window tables at the Hard Rock Cafe facing the Skydome field during a game night. Go to the Smalltalk World Tour wiki page to get instructions on how to sign up!

Tuesday, March 27, 2007

On proper use of reflection

In the past, I have written many times that we, collectively considered as mankind, suck. And I think that overall we do suck because we just shy away from looking in the mirror especially when we know for a fact we will not like what we will see.

In my opinion, there are numerous things that justify the assertion. I do not think it is necessary to bring the most glaring examples up yet again, as we have come to interact with their consequences daily.

One recent example of how we just completely suck is all the garbage that has been thrown towards Kathy Sierra. It is completely unacceptable and I hope this kind of behavior is forcefully punished as specified by law.

I also think that if we use this as a mirror, it illustrates the state of our collective mind whether we like the results or not. Either some teenagers have absolutely zero idea as to how to behave properly around people, or some adults still behave like teenagers that have absolutely zero idea as to how to behave properly around people. Regardless of which is the case, our society is failing because it allows such things to happen way too frequently.

So... can we please get a hint as subtle as "you will not threaten to do harm to others"? That should be pretty obvious, right? Ok, evidently so it's not obvious. Therefore I expect law enforcement will find those responsible and that our justice system will apply the prescribed corrective action.

I think we should not allow these crimes to go unpunished, because if we do we become accomplices by negligence. Let's not suck for a change.

Monday, March 19, 2007

Speed of a program

I briefly wrote about this in a footnote of a different post, and yet I felt it deserved proper treatment. Here we go.

In the past, I had discussions about what does it exactly mean when you say "program x is faster than program y by so much". Something that I noticed is that the speed of a program is sometimes not well understood.

For example, if you say Program A is 25% faster than Program B, what do you mean exactly? Here are some of the interpretations I have encountered:

  • If Program B's time is 100%, then Program A finished in 75% of that time.
  • Take Program B's time, divide by Program A's time, and you obtain 1.25.
  • Take Program B's time, subtract Program A's time, divide by Program's B time, multiply by 100%, and you obtain 25%.
  • Same as above, divide by Program A's time instead.
What is interesting is that any of these appears to be consistent in its own context, sometimes with surprising consequences. For example, with one of the definitions above, you cannot ever have a program be >100% faster than another one. I've run into many of these definitions, and in my experience all of them have strong believers.

I also strongly believe in one of the intepretations above because it is based on the definition of speed. So what is the speed of a program in the first place?

We are all familiar with what miles or kilometers per hour mean in terms of speed. Basically, it's some unit of distance traveled per unit of time. But what would be the distance to measure for a program? I think something that makes sense is that the distance a program travels towards the completion of its assigned task is precisely that: whether it finishes its job or not.

Let's call the unit of measurement of distance traveled by a program an iteration. Therefore, our unit of speed is iterations per second.

So now, what does it mean exactly to say that Program A runs 25% faster than Program B? That Program A completes 25% more iterations than Program B in the same amount of time. Note that this means that each iteration of Program A will complete in 80% (not 75%) of the time it takes for Program B to complete an iteration, because 1/1.25 = 0.8.

Furthermore, what does it mean exactly to say that Program A runs, for example, 2 times faster than Program B? That Program A completes twice as many iterations than Program B in the same amount of time. Note that this means that each iteration of Program A will complete in 50% of the time it takes for Program B to complete an iteration, because 1/2 = 0.5.

As you can see, the assertions "runs 100% faster" and "runs 2x faster" are equivalent under these conditions.

Finally, what happens on edge cases, such as when for example Program B is 100 null operations and Program A has zero instructions? Then Program A is infinitely faster than Program B, because Program A can complete an infinite amount of zero cost iterations with ease.

To summarize then,
  • The speed of a program is the amount of iterations per unit of time (e.g. seconds) it completes.
  • Program A is x times faster than Program B if and only if Speed A / Speed B = x.
  • Program A is x% faster than Program B if and only if (Speed A / Speed B) - 1 = x/100.
Have a nice day!

Either way it hurts

The RIAA sued a lady alleging copyright infringement. When the lady countered with "show me evidence of infringement", the RIAA could not produce any and as such withdrew the suit.

So far so good, but it gets better. The lady then asked for attorney fees because the RIAA's suit was a bunch of BS. The RIAA said "ah no the amount she asks is ridiculous". Ah, how unfortunate for the RIAA... there's plenty of legal background that says that one way to determine how reasonable attorney costs claims are is to see how much the other side spent. The judge eventually got tired of the RIAA's games and ordered them to produce such records.

Ah but then such records would become public records...

Option A. RIAA's costs are negligible. Therefore they prove they don't prepare their cases at all. Horrible PR for everybody to see. Plus of course, it provides lovely legal reputation for everybody to bring up whenever they wish.

Option B. RIAA's costs are not negligible. Therefore, since they don't prepare their cases at all anyway (i.e.: suing without evidence), that's bad PR part one. Moreover, essentially anybody that is sued by the RIAA without proper evidence gets to claim reasonable attorney's fees as well. Therefore there is even worse PR: people now have a great incentive to strike back at their racketeering-like behavior.

Oh, by the way... since the RIAA initially refused to provide such records on bogus excuses and the issue had to be escalated through the court, the lady is also asking for attorney fees due to RIAA's lack of cooperation in assessing the reasonableness of her initial attorney fees claim. Lovely.

So my friend, what is the pain dial going to point at on March 26? Pain, or more pain?

Thursday, March 15, 2007

Software performance under Windows

While doing tests for the VisualWorks VM, I found that the performance was very unstable in multicore/multicpu boxes running Windows. Speed would swing by factors greater than 2, and there was quite a bit of jitter between runs.

It turns out that what is going on is that the Windows process scheduler frequently swaps the core/cpu for processes, leading to CPU cache thrashing. This apparently happens with any single threaded program.

What is a bit surprising to me is that, although this was not news to people dealing with highly technical implementation details, I do not remember reading anything about this in mainstream hardware review sites. Strangely, I do recall reading things like "only 5% performace degradation between single core and dual core at the same clock speed" instead. Did I missed the relevant article completely?

Well in any case, here is a preliminary workaround for the negative interaction between Windows' process scheduler and multicore/multicpu boxes. Simply get the utility imagecfg.exe from either the Resource Kits or SDKs from Windows and do this:

imagecfg -u vwnt.exe

or, depending on which VM you use,

imagecfg -u visual.exe

(If you do not have imagecfg.exe handy, then simply get it here --- thanks to Oracle for the link, I couldn't find a link at Microsoft after 5 minutes of searching... ???)

Now, each time you start VW, Windows will automatically assign a different core/cpu to the new instance of the VM, and thus you will see notional performance numbers from the virtual machine or any other program you configure this way.

Make sure the executable file is not read only, because otherwise imagecfg will fail with a generic error stating it could not load and map the executable file.

The autoassignment behavior has been verified in Windows XP SP2. The performance issue has been confirmed with Windows XP Home Media Center as well, and with a variety of software such as WinRAR and demos from www.scene.org. More details to come as they are available.

PS: Doesn't it feel uncomfortable to know that your Windows box could be, essentially, throwing away up to 60% of its potential performance?

Wednesday, March 14, 2007

Smalltalk everywhere

Hola! Smalltalk is indeed everywhere. One place where it has a very large community, and where a very interesting set of applications have come from, is Argentina. Here are two very good examples of this (text in Spanish):

Cincom will officially visit this exciting place in the second half of May. If you would like to meet with us, please let us know. See you there!

Sunday, March 11, 2007

2007 Smalltalk Coding Contest Announcement

The Smalltalk Industry Council Announces the Third Annual Smalltalk Solutions Coding Contest

The Smalltalk Industry Council (STIC) is pleased to announce the third annual Smalltalk Solutions Coding Contest. The Smalltalk Solutions Technical Conference being held in Toronto Canada April 29-May 2, 2007 will serve as the home for the coding competition finale. Smalltalk Solutions is the premier forum for bringing together Smalltalk users, developers, vendors, and enthusiasts.

Coding contest prizes include:
  • 1st Place - iPod Video
  • 2nd Place - iPod Nano
  • 3rd Place - iPod Shuffle
Each of the finalists will also receive a complimentary individual membership to the STIC.

The Smalltalk Solutions Coding Competition is broken into 2 phases of competition. The first phase begins on April 13 and ends on April 22, running for 10 days. Registration is open until the contest begins on April 13. Participants must register for the competition at sts2007codingcontest@gmail.com. Confirmed registrants will receive the requirements for the first phase online.

All coding must be done in Smalltalk. Conference registration is not required to participate in the first phase of the competition.

The first phase of the competition will be judged by means of an objective score based on the performance the submission. A total of three (3) winners will be selected to compete onsite at Smalltalk Solutions 2007 in Toronto, Canada. The winners of the first phase will be announced on April 25 on the Smalltalk Industry Council web site.

The Second and final phase of the competition will take place on Monday, April 30, 2007 onsite at the Metro Toronto Convention Centre during Smalltalk Solutions pre-registration. The details of the second phase of the competition will not be released to the finalists until the competition begins.

Prize winners will be announced during the conference.

Feel free to contact us regarding the contest at the following addresses: