Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

speters (1787)

speters
  (email not shown publicly)
http://www.fisharerojo.org/
AOL IM: fisharerojo (Add Buddy, Send Message)

mmm...Perl

Journal of speters (1787)

Wednesday April 12, 2006
10:06 PM

Playing with fire

[ #29307 ]

I’ve been lucky enough to recently get access to the Sun Fire T2000 that Ask and Robert have gotten from the Sun Test Drive program. I have to say that so far it has been quite fun to play with.

The architecture of the new UltraSparc chips is quite interesting. You can check out the OpenSparc website if you are really interested, but it allows each CPU to run four separate, autonomous threads, or strands, as Sun calls them. Because of this, an 8 CPU box, like the perl.org T2000, behaves like a 32 CPU box. I have to say that running gmake –j33 when developing Perl is a real time saver.

More importantly, of course, is that it has helped us to close out a few old bugs as well as help us find a few new ones. Nicholas fixed some parallel build issues that prevented the gmake gymnastics above. He is also playing with parallel testing with harness in the Perl distribution. With multiple CPU cores becoming more common (I’m expecting to see a good number of MacBooks at YAPC::NA) this will be helpful to a lot of Perl developers.

The new bugs involved a couple of additional build issues. First, Perl’s tests were making the assumption that the UNIX init proc had a pid of 1. That’s not necessarily the case on the T2000. Second, I found that the make used to build some of core modules switched from gmake to Sun make. This isn’t very helpful when you are trying to use gmake’s parallel make capabilities. I’ve got a patch that Nicholas suggested to fix this. Now, I just need to complete testing on before I commit it into the core.

Now, that we’ve kind of broken it in, I’m going to try to do some benchmarking on the box to try a few comparisons that have popped up on the perl5-porters mailing list in the recent past. One interesting one that Jim Cromie discussed was using Perlbench to compare multiple runs of a single Perl against itself. The idea is that Perl should perform with some regular consistency. One that I’m interested is comparing the performance of a big 16 CPU Itanium box against the T2000’s 8 CPUs that behave like 32 CPUs. I really want to see how the virtual CPUs compare against the real thing. Finally, I’m hoping that this platform will help point out the poor performing places in the Perl core so that I can help speed up Perl a bit in a few places. Hopefully, I won’t need a crash course in Sparc Assembly Language to do this. :)

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • To your list of "how do virtual computers behave" I would love to see how it handles something like qemu, or something else which would normally really thrash the cache.

    I'm already seeing recommendations that the dual core intels aren't usable for two qemu sessions because of that issue, I would expect the "32 processors" to show even more pronounced cache thrashing problems.

  • You can find more numbers on Colm MacCárthaigh’s weblog [stdlib.net]. In particular, don’t miss the Niagara vs ftp.heanet.ie Showdown [stdlib.net].

  • One that I’m interested is comparing the performance of a big 16 CPU Itanium box against the T2000’s 8 CPUs that behave like 32 CPUs.

    note that the niagara chip (the one in the t2000) is not powerful in number crunching and other high-cpu loads such as... compilations. it's good for multi-threading and parallel tasks, such as java application servers and this kind of stuff. so i can foresee that your 16-ways itanium box will outperform the t2000 with a high margin. but for web servers and othe

    • We use the t2000 mentioned in the blog above as a terminal server. I guess running shells for 100+ users is about as parallel as you get.