Tuesday June 28, 2005 What do you prefer - a faulty program to run slowly or to die immediately ?
Whenver we change the default compilation flag, often we have to make interesting tradeoffs. A relatively recent trade off was regarding the default value for -xmemalign (Here's the link to the exact page for the description of the flag). Starting from Studio 9, our compiler uses -xmemalign=8i in 32bit mode as default (vs -xmemalign=4s before).
With -xmemalign=4s, a program that does unaligned memory access would die right away, telling the developer what was wrong and where it went wrong. But with -xmemalign=8i, such program would simply run slowly and it's somewhat difficult to track down such a performance degradation (well, if you know where to look at, dtrace is again your friend here but you pretty much have to know the answer beforehand).
Sounds bad, so why did we do it ? The answer is again, the performance (what else?). When you compile a code with -xmemalign=8i as opposed to 4s, the compiler can safely use 8byte store and load for appropriately sized datum (like double precision floating point). Since most programs are alignment-safe, that is, most code don't do funky typecasting (like casting a char pointer to an integer point and accessing it), this change doesn't cause any performance degradation on those correct programs but actually could improve them somewhat. You can ask why not -xmemalign=8s. Unfortunately, some constructs in Fortran and the artifact of 32bit ABI in SPARC makes it not possible to use -xmemalign=8s even for a completely correct program. However, those occurrences are very rare as to not affect the overal performance in most programs, hence the decision to switch to -xmemalign=8i.
But when you're writing code, you may actually want to use -xmemalign=4s instead of -xmemalign=8i, to make it easier to find any alignment trouble in your code. Anyway, if I have some time, I'll write on how all these unaligned access works - the dance between the user code and the kernel. In the mean time, if you're in a hurry, here would be an interesting point to start looking at how kernel emulates unaligned access for 32bit apps). ( Jun 28 2005, 02:00:00 PM PDT ) Permalink
Thursday June 09, 2005 Ever heard of sound ISOLATING earphones ?
For last few weeks since I got my iPod Shuffle, I've been using this earphone to listen to my collection of music while in the office. There's a reason why it's called sound isolating - I don't hear almost any sound when I'm plugged.I don't hear my phone ringing unless I turn the ring volume all the way up. I don't hear my roommate talking on the phone (he doesn't exactly whisper when he's on the phone). I don't hear someone asking me for lunch. I don't hear my manager opening my room door (I sit facing away from the door), walking across my back and sitting down on my side. I have no idea he's there until he taps me on the shoulder. Ooops.
This earphone works...and works too well to use it in the office. So I ended up switching back to less satisfying earbuds bundled with iPod. If you're working in noisy environment (maybe in some cubicle full of noisy coworkers or rack full of servers), sound isolating earphones might be a great help. Of course, it reproduces music *much* better than others.
PS. I'd love to get this one if I have some spare cash to burn. Although mine sounds much better than most other earbuds, I know it still lacks precise high to mid-high frequency response (I'm not much of a bass person and the bass of E2c is enough for me). And like most other earphones, the sound field feels "closed". Maybe I should get one of these. ( Jun 09 2005, 09:14:00 PM PDT ) Permalink Comments [1]
Monday June 06, 2005 MacOS X on Solaris ?
Our COO invited Apple to adopt Solaris as the base of MacOS X. For those of you who don't remember or know the history behind this, this isn't the first time there's such a proposal. See our own Rich B's blog here for a bit of history. In fact, OpenSTEP implementation was working (including Mail.app albeit with fonts rendered ugly compared to native NeXTSTEP). FYI, our COO used to work for a company called Lighthouse Design which used to produce softwares for NeXTSTEP.
I used to run NeXTSTEP 3.3j on my SPARCstation, as well as the earlier versions of OpenSTEP on Solaris. All NeXTSTEP GUI applications were great - it indeed was 10 years ahead of everything. However, mach kernel and BSD server in NeXTSTEP was...at best flaky and slow and it was clearly behind Solaris at the time. I think it will take years for darwin to catch up with Solaris 10 - evidence ? OS X has very recently added 64bit support or fine grained locking/reentrant kernel and it's been years since Solaris had those. And it will take even more time for Apple to catch up with all those new features in Solaris 10 - Dtrace, Zones, ZFS, FMA and etc. IMHO, it would make perfect sense for Apple to switch to Solaris 10 on x86 replacing Darwin. Here's hoping that Apple will consider switching to Solaris :)
PS. I know. It's even less likely than Apple's switch to Intel. But surely one can have a dream. ( Jun 06 2005, 10:33:44 PM PDT ) Permalink Comments [3]
Friday June 03, 2005 How Apple can move to Intel
CNet reported that Apple is going to switch to Intel for its CPU supplier. Some people thinks that this means Intel will produce PowerPC compatible processor, but I strongly doubt it. Some other people thinks that this would involve mostly emulation of PowerPC on x86. However, I have slightly different take on this - I think Apple is going to use FAT binary to smooth the transition.NeXTSTEP used to support FAT binary for four architectures - Motorola 68k, Intel x86, HP PA and Sun SPARC (NIHS). And it worked pretty well. Gcc compiler for NeXTSTEP had an option to produce objects for all four targets at the same time, and linker and runtime loader all supported this very well. A single executable file can contain object codes for four different architectures, and many applications were distributed for all four (NIHS), or at least for 68k and x86 (NI).
Assuming Apple didn't remove FAT support in MacOS X, it would be fairly easy for Apple to provide developers ways to create executables for both targets (a simple recompilation for both target would work for most applications, just like moving applications from Solaris SPARC to Solaris x86) and the ISVs can distribute one software package that supports both platforms.
Of course, Apple may still need to provide a PowerPC emulation for x86. But that shouldn't be too difficult either, since underlying OS and APIs remain the same. But emulation doesn't address the actual transition of ISV code itself, and it alone doesn't really ease the transition for ISVs like FAT binary does. So all in all, I bet Apple will revive FAT binary in OS X. Maybe it's time for Sun to push SPARC support in OS X...after all, Niagara and ROCK will be quite attractive as a CPU for Xserve :) ( Jun 03 2005, 10:58:57 PM PDT ) Permalink Comments [1]