mattst88's blog - The Case for Open Sourcing Alpha-Optimized Libraries

My Daily WTF moment

I read The Daily WTF from time to time in amazement. I've never had a WTF moment even relatively worthy of their site, until today...

                        <?php  if (isset($secondary_links)) : ?>
                 <?php  print theme('links', $secondary_links, array('class' => 'links secondary-links')) ?>

		    <?php

		                               endif;

					                                   ?>

This is exactly how the code appears, spacing included. Fixing up the spacing only makes you wonder why-tf anyone would write PHP in this style.

<?php if (isset($secondary_links)): ?>
<?php print theme('links', $secondary_links, array('class' => 'links secondary-links')) ?>
<?php endif; ?>

So what's wrong with this code?

1. Spacing–the author had to try to make it this atrocious
2. Opening and closing <?php for consecutive lines–what gives, really?
3. Wonky if(): endif; syntax–are we in 1998 again

By the way, writing unreadable code does not help your job security if you have to ship it to customers.

21 October 2009 – Tags: rant work

Socket 754 Turion ML-34 works in an ABIT NV8

My current desktop has served me quite well for nearly four years. Its Sempron 2800+ certainly doesn't compete with Phenoms or Core 2's in terms of performance, but what really bothered me about it was its lack of power management support. By some arbitrary decision, AMD chose to disable Cool'n'Quiet on Semprons <3000+. I've been vaguely interested in upgrading the processor for a while, but options are rather limited. It's not worth it to upgrade to a faster Sempron. Socket 754 Athlon 64s use quite a bit more power and mobile Athlon 64s still cost well over one hundred dollars. Socket 754 Turions exist, but I couldn't find any mention of compatibility with my ABIT NV8. I figured for eight dollars it was well worth the gamble, and bought a mobile Turion ML-34 on eBay to give it a try and to give my desktop a final upgrade.

So the specifications of the two processors are

Being mobile processors, Socket 754 Turions don't have a heatspreader separating the die from the heatsink. To allow my Scythe Ninja heatsink to make contact directly with the core, I removed the black heatsink mounting equipment from the motherboard and shaved down about 2 millimeters from the bottom. After some adjustment it fit, and the heatsink made good contact. Once this was set, I fired it up. The BIOS even recognizes the Turion by name.

No benchmarks unfortunately, nor have I had a chance to test power consumption with my Kill-a-Watt. I can say that the CPU runs about 5 ℃ cooler. Linux also is able to change the CPU frequency on the fly between 1.8 GHz, 1.6 GHz and 800 MHz.

So I can confirm to any Socket 754 users left out there that Turions do work in the ABIT NV8. It's probably the most satisfying upgrade Socket 754 users as well.

06 October 2009 – Tags: hardware

IRIX for x86 and the 700MHz O2

As I was testing Radeon Kernel Mode-setting on Alpha, I casually started a conversation with Jesse Barnes, an Intel Graphics developer. I recalled that he was an ex-SGI employee, and being interested in SGI computers myself decided to ask him a question or two. What I learned about SGI absolutely floored me.

When Chicago Joe hacked a 600 MHz PMC-Sierra CPU into an SGI O2, the quest for newer, faster chips for the aging O2 began. 600 MHz is a nice upgrade, but why stop there? A 900 MHz CPU should be possible as well, but it would require changes to the O2's PROM at the source level. Due to one thing or another, SGI has been unwilling to release the PROM source code. I decided to ask Jesse if he knew the right people to contact at SGI to lobby for the release of the code.

The conversation went –

<mattst88> jbarnes, you used to work at SGI, no?
<jbarnes> yep
<mattst88> the holy grail of O2 hardware hacking is replacing the desoldering the CPU and replacing it with a a 600 MHz chip.
<mattst88> theoretically, 900 is also doable, but it would require the release of the O2's PROM code
<jbarnes> I played with some that had pmc 700MHz chips
<mattst88> rumor has it that Microsoft owns most of the code, from the MIPS consortium days
<jbarnes> I think we ended up not shipping due to some weird fp bug
<mattst88> any idea if SGI is even _able_ to legally release this code?
* jbarnes even did an irix kernel patch for that chip
<mattst88> btw, SGI just got bought out.
<jbarnes> yeah I'm still in touch with people there
<jbarnes> yeah they could release a lot of it
<mattst88> jbarnes, _SGI_ was going to ship 700 MHz chips for the O2?
<jbarnes> it's just a pain due to external contractors doing some etc
<jbarnes> yeah
<jbarnes> we even did an x86 port in 2000
<mattst88> never heard that before, that's cool stuff
<mattst88> x86 port of IRIX?
<jbarnes> yep
<mattst88> holy crap
<jbarnes> well time to go home...
<mattst88> do you think it's possible to pull the right strings to get as much code as possible to be released?
<mattst88> the PROM, that is?
<mattst88> btw, do you mind if I reproduce this conversation?
<jbarnes> sure sgi got sold so I guess it's ok for it to be widely known
<jbarnes> as for the prom... dunno who you'd talk to about that these days
<jbarnes> rich altmier is at intel now, otherwise he'd definitely be the guy
<mattst88> if you get any ideas, please let me know. there are definitely a lot of people who would love to hack at it
<mattst88> so, any more secret tidbits to share before you head for home?
<jbarnes> hehe
<jbarnes> I'm sure someone will write a book
<mattst88> why was the IRIX port to x86 not released?
<jbarnes> just show up to la fiesta in mtn view on any given wed evening and keep your ears open
<jbarnes> various reasons
<mattst88> saving them for the book? :)
<jbarnes> heh
<jbarnes> ok bbl
<mattst88> do you mind if I reproduce this conversation?
<jbarnes> sure np
<mattst88> thanks

*blink*

• IRIX for x86
• 700 MHz PMC-Sierra chip for the O2, by SGI

No commentary needed...

09 April 2009 – Tags: irix sgi

Ideas for the Future of SkyOS

In December 2004, I paid thirty dollars for a SkyOS Beta membership. I was intrigued by the project. I couldn't explain it. It was just different. I ported simple software and came to be a part of the SkyOS community. I wrote SkyOS programming guides. I spent hours talking with other SkyOS users on IRC. I reported bugs and followed development closely. There was no other project that I devoted more time to than SkyOS. But for the last year or so, SkyOS has progressed at an ever slowing pace. With long periods of downtime between SkyOS releases, many users, myself included, gradually moved on to other projects. Finally, Robert made the announcement that SkyOS development is officially halted. I wasn't surprised, but I was saddened. Given what I know of the project and of Robert, and having seen in four years of development the same concerns raised, problems faced and subsequently fixed over and over again, I wrote a letter to Robert outlining what needs to be done to save his hobby of the last thirteen years.

Hi Robert,

This is Matt (mattst88) from SkyOS.

I read your response on OSNews. I want to comment on your possible resorts:

• Open source SkyOS
• Make SkyOS available for free
• Specialize on a yet to define niche

Do all of them, by

1. Releasing SkyOS as open source/free software under the MIT or BSD license. By licensing under a very permissive license, it will allow projects from whom SkyOS has used code (e.g. Haiku) to use SkyOS's code where possible.

2. Implementing a Linux-style development model. Source code would be available in a public git repository, of which you would be the only one with commit access. You, and you alone, would:

   1. control what goes into the repository
   2. define targets and make releases
   3. point people in the right direction

   This way, others do the heavy lifting and you help where needed.

   Once this has been done, I see a number of things that can be done to improve SkyOS.

3. Move SkyOS-specific code in ported software upstream. As an open source project, it should be much easier to have official support from other open source projects.

4. Reduce development time and duplication of effort by replacing SkyOS components with open source counterparts. As I have not viewed the SkyOS source, I cannot comment further on which components could be replaced.

5. Port the Direct Rendering Manager to the SkyOS kernel. With DRM in place port Gallium3D [1], which should _greatly_ simplify graphics drivers. Using Gallium3D, SkyOS would be able to leverage support from a much wider base of developers.

6. Finally, define a niche for SkyOS to fill. Laptops are more likely to have nonstandard hardware, thereby requiring all kinds of extra support, from strange integrated graphics chips, to countless wireless chipsets, to docking stations. (I do not mention power management, as it is becoming increasingly necessary even for desktop systems.) I therefore propose supporting only standard desktop systems.

I hope you find time for SkyOS in the future and implement my suggestions. With this plan, SkyOS should live on with community support, and you should be able to devote time to your daughter (I guess she has just turned one?) and family.

Thanks Robert, for everything. I'll turn 21 this month, graduate with a degree in Physics next year, and go to graduate school in either Computer Science or Computer Engineering the year after. I can definitely say that SkyOS has contributed heavily to developing my passion -- computers. I've learned so much from this project. I know there's still much to learn from you and from SkyOS, so I hope you continue the project.

Thanks again,

Matt Turner

[1] http://www.tungstengraphics.com/technologies/gallium3d.html
     http://www.tungstengraphics.com/wiki/index.php/Gallium3D
     https://en.wikipedia.org/wiki/Gallium3D

I sent this email almost two weeks ago. I have received no response.

As an addendum to my email: SkyOS should further limit its hardware support by supporting only x86-64 systems in 64-bit long mode.

Another long time SkyOS user told me via IRC that he believes Robert has entirely lost interest in SkyOS. Evidently, he didn't even notice that SkyOS.org was down for two to three days after OSNews ran its article.

I sincerely hope he is wrong, but I can only doubt his claim so much. If SkyOS is not dead – great, let's see how we can give it new life and contribute to projects on which we've drawn support an inspiration. If it is dead, it was a fun hobby for Robert, me, and others involved. I certainly learned a lot and cut my teeth on SkyOS.

13 February 2009 – Tags: skyos

The Case for Open Sourcing Alpha-Optimized Libraries

As long as I've been interested in Alpha hardware, I've been intrigued by Compaq's Alpha-optimized compilers and libraries. In some cases, the compilers produce code multiple times faster than by gcc. The math library, libcpml, contains functions that execute in half the time of their glibc equivalents. Since the abandonment of the Alpha platform, this code has languished. In some cases, the performance gap between Compaq's tools and their open source counterparts has shrunk. In others, the benefits of hand-tuned assembly still shine. This prompted me to contact HP and request the release of the code. They unfortunately concluded that an old MIPS license prevented them from releasing the compilers. I've recently contacted HP once again to persuade them to release libcpml and libots as free software, as libraries containing nothing but hand-tuned Alpha assembly could not be encumbered by this license. I also attached the following benchmarks as evidence of why this code is still valuable so many years after it was written.

Using a test suite I wrote, I benchmarked the implementation of math functions found in glibc with those in libcpml.

As can be seen, many math (especially trigonometric) functions are 50-200% faster in libcpml. In other cases, such as the rounding functions, glibc is faster.

A few notes:

• Testing was done on my UP1500 with an 800 MHz EV68AL, 8MB L2 cache, and 4 GB RAM
• It may not be fair to benchmark ceil/floor as their implementations in glibc are not correct
• I don't entirely trust the glibc tan results, as they appear to be 50x slower than libcpml

As more evidence of libcpml's superiority, by simply linking nbench with -lcpml instead of -lm, the fourier benchmark gets a speed up of 2.5x to 3.0x.

If you'd like to run this test yourself, here's how. (I assume you run Gentoo on your Alpha.)

• Download libcpml for your processor, EV5, EV6 or later
• Add the libcpml ebuild to your portage overlay

  svn co svn://mattst88.com/svn/compaq-c-overlay/

• Install libcpml (and its libots dependency) and make sure to set the ev6 USE flag if your Alpha is an EV6
• Checkout the test suite with

  svn co svn://mattst88.com/svn/cpml-benchmarks

• Edit the CFLAGS variable in Makefile for your processor
• Run

  make test

  from the cpml-benchmarks folder
• A results.csv file is generated in the cpml-benchmarks folder. Analyze results using a Spreadsheet program

If you like, email the results to me. I'd like to see what these benchmarks look like on an EV5 machine.

11 January 2009 – Tags: alpha linux