21 October 2009 - 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.

06 October 2009 - 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

Sempron 2800+ Turion ML-34
Frequency 1.6 GHz 1.8 GHz
L2 cache 256 KiB 1024 KiB
Power consumption 62 W 35 W
Power management No Yes

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.

09 April 2009 - 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*

No commentary needed...

13 February 2009 - 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:

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
     http://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.

11 January 2009 - 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.

Function Library Run 1 Run 2 Run 3 Run 4 Run 5 Run 6 Run 7 Run 8 Run 9 Run 10 Average Speed Up (cpml over glibc)
sin glibc 311 292 312 310 297 304 307 300 312 312 305.11
sin cpml 156 155 148 150 152 154 152 151 151 163 152.89 99.56%
cos glibc 251 246 245 243 392 251 240 240 252 240 261
cos cpml 156 151 153 160 159 160 146 149 151 157 154 69.48%
tan glibc 9384 9345 9351 9252 9195 9273 9237 9272 9213 9239 9264.11
tan cpml 172 169 168 166 168 173 170 176 183 175 172 5286.11%
sinh glibc 305 296 296 302 291 295 437 295 294 298 311.56
sinh cpml 141 136 140 139 135 139 137 140 136 139 137.89 125.95%
cosh glibc 352 327 316 363 351 338 352 358 329 362 344
cosh cpml 138 139 137 141 140 142 138 138 144 138 139.67 146.29%
tanh glibc 260 258 270 260 266 260 263 257 265 256 261.67
tanh cpml 212 203 199 203 203 198 210 195 212 198 202.33 29.33%
asin glibc 1434 1197 1227 1300 1346 1323 1390 1227 1274 1244 1280.89
asin cpml 627 611 581 641 612 596 660 586 620 692 622.11 105.89%
acos glibc 1034 1207 1054 1015 1015 1031 1068 994 1051 964 1044.33
acos cpml 621 625 657 635 610 638 587 623 617 614 622.89 67.66%
atan glibc 932 860 904 904 866 902 948 879 908 880 894.56
atan cpml 566 536 538 519 538 513 521 533 526 497 524.56 70.54%
asinh glibc 784 743 749 741 742 773 751 726 784 743 750.22
asinh cpml 519 513 506 494 527 494 494 529 495 510 506.89 48.00%
acosh glibc 912 866 855 785 990 823 865 820 845 836 853.89
acosh cpml 954 912 898 946 905 904 898 920 928 885 910.67 -6.23%
atanh glibc 1125 1939 1071 1053 1079 1085 1068 996 1062 1143 1166.22
atanh cpml 875 898 851 828 912 864 843 871 1355 851 919.22 26.87%
floor glibc 88 82 82 79 76 91 87 84 84 86 83.44
floor cpml 121 123 128 120 121 119 117 120 126 112 120.67 -30.85%
ceil glibc 89 90 85 85 86 79 81 80 81 80 83
ceil cpml 123 117 115 114 131 114 119 114 122 118 118.22 -29.79%
round glibc 102 77 78 90 85 87 77 83 85 84 82.89
round cpml 366 111 115 102 118 112 108 107 109 111 110.33 -24.87%
trunc glibc 84 83 87 89 77 84 82 85 85 84 84
trunc cpml 118 120 118 117 116 119 112 109 114 110 115 -26.96%
log glibc 790 764 767 763 768 768 732 739 744 747 754.67
log cpml 502 456 476 476 465 460 922 484 481 456 519.56 45.25%
log10 glibc 840 803 808 802 784 856 785 782 774 826 802.22
log10 cpml 527 534 549 551 536 578 535 530 540 537 543.33 47.65%
log2 glibc 493 499 522 504 478 504 519 495 499 539 506.56
log2 cpml 520 493 514 509 481 520 493 493 493 728 524.89 -3.49%
log1p glibc 233 240 235 224 234 230 227 228 229 233 231.11
log1p cpml 304 279 276 297 269 299 291 291 305 286 288.11 -19.78%
exp glibc 401 357 357 403 344 407 413 475 372 401 392.11
exp cpml 130 138 132 128 133 139 124 130 137 126 131.89 197.30%
expm1 glibc 225 205 218 208 214 213 216 211 221 208 212.67
expm1 cpml 160 165 169 157 166 162 157 164 165 157 162.44 30.92%
exp2 glibc 1339 1314 1327 1305 1339 1310 1284 1284 1334 1309 1311.78
exp2 cpml 151 149 136 140 148 137 139 149 138 138 141.56 826.66%

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:

As more evidence of libcpml's superiority, by simply linking cleanbench 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.)

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

1 2 3 Next

MathML XHTML CSS Tableless UTF-8