It basically answers all the questions you had in your post. I had noted this article when it appeared and only got to reading it a month ago. A bit too verbose for my taste, but worth the time nonetheless.
Itanium2 has probably the shortest pipeline of any processor running at or above 1Ghz (can't remember if it's 7,8 or 9 stages). So much for very long instruction pipelines.
You probably misunderstood "very long instruction words" for very long pipeline. And Itanium isn't even a VLIW processor, although it was inspired by VLIW. If you complain about that, you could also complain about the Power4 instruction group mechanism.
Actually, the very long instruction pipelines on Itanium make it inefficient for systems with large numbers of processors.
Ahahaha:-). Check the SpecJBB scores someday (where a 32way Itanium system beats a 64way Sun, same result for 64way vs. 106way). Or maybe the TPC-H scores ? Or any other benchmark where you can compare high-end Sparcs versus high-end Itanium systems.
You'll also see that Sun isn't publishing numbers for some of those benchmarks (TPC-C for example). Do you really believe that it's because of flaws in the benchmark ?
Let's compare: SPARC at 1.2GHz has SpecINT of 642 and SpecFP of 953.
HP Integrity Server rx2600 (1500 MHz, Itanium 2) SpecINT 1322 SpecFP 2119 Ouch more than twice the performance at 25% higher frequency (and without Sun's SpecINT compiler cheat). As far as scalability go, a Superdome 32 processor beats a 74way Sun on SpecJBB (while the 64way Superdome beats the 106 way Sun). Solaris isn't the only game in town when it comes to scaling, and you don't always need the same scaling when each processor performs well.
Xeons are not 64-bit CPUs
Ah but Itanium CPUs are, you might want to compare Sparc processors against high-end processors. Now if you want to compare price/performance, sure, feel free to include Xeons and Opterons too.
The SPARC architecture will always outperform an Intel architecgture, even at 1/100 of the clock speed.
How can you be so deluded ? Are you a Solaris sysadmin in denial ? A Sun employee ?
You might want to check Spec CPU, TPC-C, TPC-H, SpecWeb, SpecSSL, Linpack, SAP benchmarks someday (I am probably forgetting some). And remember that Sun is cheating as much (or more, cf. their controversial Spec CPU optimizations) as the other vendors, so don't come back complaining about benchmarketing.
Also note that the competition isn't always a Xeon processor running Linux.
If these people (or Brad) were thinking at all toward the future they would have made the cards BIGGER not smaller.
My understanding is that the PCI-Express folks are working on a cartridge standard for "full size" cards (think PCI-card level functionality). This may come with the 2nd generation signaling rate (up from the 1st generation 2.5 Gb/s/lane). The goal is to allow users to add/remove cards from desktops/servers without having to open them (or even without having to shut them down). This should make card manufacturers smile, I know quite a few people who don't upgrade their PCI cards simply because they are scared of opening them.
I expect the typical 2008 full-size desktop to have one or two cartridge slots and a few ExpressCard slots. The cartridge slots would be used for power/space-hungry applications (Video, multi-IO cards, optical connections, solid-state disks), while the card slots would be available for other extensions (smart card reader, UWB adapter cards, FW 1.6 adapters,...).
Pins ? I don't see pins. Where do you see pins ? IIRC this is a beam connector with low contact counts. The connector carries power(s) + 1 USB 2.0 connection (480 Mb/s) + 1 PCI-Express 1x connection (2.5 Gb/s) + 1 management connection.
Why USB seems obvious to me. For some applications a 1x PCI-Express connection is going to be overkill. Think smart card readers (how many bits/s ?), modems, serial adapters (e.g. to get data from older equipment like a weather station, to slide projectors, home automation equipment, etc). Heck, USB 1.1 would be enough (or already too much). USB2 is today's equivalent of a cheap RS232 connection. When it's enough, it's enough. You do not always need 2.5 Gb/s:-)
Firewire doesn't make much sense as an internal connection. Too much overhead in the protocols employed, too many transistors required to get the base functionality. Please don't get me wrong, I love FW, I am not victim of USB 2 performance claims and I want to see 1394b connectors on every machine.
I don't blame you for your reaction though. When I first heard about the USB part of the spec I had the exact same reaction. However I had the chance to discuss this with some of the folks working on this specification. I now see why it makes sense.
I am afraid the release notes are a bit misleading.
The HW acceleration in 1.3.1 and in 1.4.1 are different beasts. 1.4.1 uses Quartz Extreme acceleration (layers/compositing), while 1.3.1 was accelerating 2D drawing (and adding visual glitches in the process).
If you follow the java-dev mailing lists, you would see posts from Apple employees mentionning that they intend to bring back the HW acceleration for 2D drawing (IIRC Gerard Ziemski said that recently).
Re:Why Apple didn't use X for the window system
on
Mac OS X Maximum Security
·
· Score: 2, Informative
FYI, the parent post appears to have been posted by Mike Paquette, who designed/wrote a good part of Quartz. His post is more than "+5 Informative", it should be "+10 Reference".
Apple's OSX does all rendering through Quartz, (as PDFs) which is accelerated by OpenGL, and called QuartzExtreme.
That's not accurate. Quartz is really made of two parts: Quartz 2D and the Quartz Compositor.
The Quartz Compositor is reponsible for compositing all the layers (desktop, windows, layers inside windows) on-screen. It offers Porter-Duff compositing, which was developped at Pixar more than 15 years ago. See this post from Mike Paquette for details. Mr Paquette is one of the main developpers of Quartz. Quartz Extreme is "simply" an OpenGL implementation of Porter-Duff compositing and modern graphic cards offer the primitives needed to do that very efficiently.
The Quartz 2D layer is what offers drawing primitives following the Postscript drawing model. The same drawing model is used with PDF (no surprise), Java2D and SVG (and Microsoft's GDI+ ?). This part is not HW accelerated. I am sure Apple is working on it, but it wouldn't surprise me if new HW will be required to make this possible. There is a strong incentive for card manufacturers to offer acceleration, since Longhorn is supposed to use GDI+ extensively. I doubt that such acceleration will fit in the traditionnal OpenGL/Direct3D rendering pipeline.
The Apple JVM team implemented HW accelerated Java2D drawing in their 1.3.1 JVM. Their 1.4 JVM doesn't offer it (1.4.1 was a massive rewrite for them, 1.3.1 was more of a quick port to OS-X using some of their "old" carbon code). There were quite a few problems when HW acceleration was used. I hope they can and will wait for a system-wide Quartz-2D HW acceleration, it seems ludicrous to have the JVM team spend resources on an effort that will be wasted once Quartz2D is accelerated.
In a talk at UCLA a few years back, a professor mentionned that the "isolation" doesn't work so well in practice. It turns out that even using different languages and different programming teams, there are always bugs that end-up in all versions.
There are many ways for an OS to be "a 64-bit OS". However programmers/users of existing 64bits OSes will typically check a single criterion, which is unlikely to be met by OS X 10.3.
1. An OS could be called "64bits OS" because it allows programs running on the computer to use 64bits-instructions, while leaving them with 32bits pointers. This is typically done by offering a 64bits datatype (int64_t/uint64_t in C99 compliant environments) and a compiler that will emit the right instruction sequences. It also requires that the underlying OS will be made somehow "64bits aware", ie that it will save/restore the full 64bits content of processor registers on context switches. My understanding is that Panther/10.3 will allow that, or at least most of that.
2. An OS could be called "64bits OS" because parts of the kernel (VM / buffer cache,...) can make use of memory beyond the 4GB limit by using specific APIs that work around the 32bits pointers limitation. I hope that Panther will allow that.
3. An OS could be called "64bits OS" because it allows the usage of more than 4GB of memory by all userland processes, while any given process is still limited to 4GB (32 bits pointers). My understanding is that Panther will do that.
4. An OS could be called "64bits OS" because the kernel code is compiled to follow a 64bits ABI (Application Binary Interface). In such an ABI, pointers are 64bits entities and some integer types are also 64bits. While an ABI covers _a lot more_ ground than just the size of the common C types, those sizes are often used to characterize the ABI. The most common 64bits ABI is known as LP64 (aka I32LP64) where "int" remain 32bits, while "long" and "void*" are 64bits. By comparison the most common 32bits ABI is known as ILP32 (int, long, void* are all 32 bits). I don't think any "common" OS offered a ILP64 model (Cray maybe?). Windows64 is a different beast, being LLP64 (aka IL32 LLP64), where int and long are 32bits, while "long long" and pointers are 64bits. My understanding is that this will _not_ be the case for Panther, the kernel code will be compiled with a ILP32 ABI.
5. An OS could be called "64bits OS" because it offers a 64bits ABI to userland applications compiled in "64bit mode". My understanding is that this will _not_ be the case for Panther, all code will be compiled with the traditional ILP32 ABI.
My "belief"/"understanding" of the Panther situation comes from reading the WWDC reports, rumours reports and also the Darwin development mailing list where one Apple employee said that OS X won't offer an LP64 ABI until much later (not in Panther, at _least_ not in 10.3.0 and I doubt any 10.3.x release).
Most current users of 64bits systems will only use criterion 5, but I expect Apple PR to try to muddle the issue. And I won't blame them much, the issue is not as clear cut as some users think.
Some tidbits related to 64bits platforms:
- HP-UX 11.00 shipped as two different kernels, one 32bits kernel and one 64bits kernel. 64bits machines could run either of them, while 32bits machines were restricted to the 32bits kernel. On the 64bits kernel a user could run 32 and/or 64bits processes, while the 32bit kernel could only run 32bits processes. It sometimes made sense for the owner of a 64bits machine to only install the 32bits kernel, if they didn't intend to run any 64bits application and didn't have more than 4GB of ram (rare then). Running the 64bits kernel typically consumed a bit more memory and consumed a bit more memory bandwidth.
- Linux on 64bits machines is "pure" 64bits (today, this may change due to ISV pressure). It doesn't run anything but programs compiled with the 64bits ABI (I32LP64). A special case is Linux IPF (IA64) which also runs 32bits apps, but those aren't "native" applications using the Itanium ISA but x86 binaries running using the hardware (now) or software (future) emulation. Another special case will be Linux on x86-64 which also has to run "emulat
What you are describing isn't benchmarking, it's stress testing.
Benchmarks are meant to predict performance. While it is essential to check the validity of the answer (wrong answers can be computed infinitely fast), the role of a benchmark isn't to check never-seen-in-practice cases or so-rarely-seen-in-practice-that-running-100x-slowe r-won't-matter.
That reminds me of the "graphic benchmark" used by some Mac websites that compares Quickdraw/Quartz performance when creating 10k windows. Guess what, Quartz is slower, because Quartz windows are a lot more powerful/heavyweight than Quickdraw ones. But who gives a fuck, how often do you need to create 10k windows in a hurry ? No one, apart from those OS 9 zealots who are looking for ways to bash OS X. A realistic benchmark may to check to at most 10s of windows, but the conclusion would probably be that the difference in speed isn't observable by humans.
A good benchmark can only be judged by comparing its execution profile against what users will run. If it's not reflecting the reality, it's not an appropriate prediction of the performance for the user. And it's not a binary property. While Spec is by definition perfect for anyone that only runs Spec, it is known and accepted to be imperfect at anything else, and a completely useless predictor in some cases (as in very low statistical correlation between Spec scores and speed at running Foo). It's just a "best effort" suite of tests for workstation applications. I'm talking SpecINT / SpecFP here, other Spec benchmarks exist because (gasp!) SpecINT/FP don't cover the whole computing spectrum.
You also don't seem to have much of a clue about how processors are really tested. Guess what, the processors people do all that you describe and more, much more. All day long on many, many samples, for months on end, in good/bad conditions (thermal, electrical). It's just that no test suite can catch all the problems, so defects will always slip by. _Always_, even if the logic is formally proven correct, since processors aren't mathematical entities but subject to electrical / manufacturing variations. Even if no problem exists today on a given CPU, take a hundred of them from various batches, power-cycle them a few million times, run them for a few years in marginal conditions and check again.
There is one non-backward compatible change I'd like to see embraced: put the optical media in a _thin_ cartridge.
I believe blue-ray is such, but from what I read blue-ray is not really meant as the next-gen DVD format, mostly as a format for recorders and computers. And one of the reason cited is the cartridge:(
I would prefer a format where the media is protected better than current CDs and DVDs. A format that could be grabbed by a reader more reliably than the current (cf. slot-loading readers on Mac). I don't understand why so many seem opposed to such a change. Maybe some people imagine something similar to the old CD caddies, where you had to place the regular format in a cartridge. I rather imagine a format that is always enclosed in a cartridge, like the 3 1/2" floppies.
Conspiracy theory: RIAA/MPAA execs don't want this to happen, as they know more people would lend their CDs/DVDs to friends if the media was made more resistant to abuse.
For the record: I don't believe that for a second.
No, Mac OS X does _not_ allow for multiple servers in the Mach 3 sense.
Darwin is a monolithic kernel where BSD is wedded to the Mach services (bound, not semi-bound). Cocoa and Carbon are purely user-space entities. Classic does have some support in the kernel but it is _not_ a server in the Mach sense, and it is also mostly a user-space thing.
From following the Darwin mailing lists, you seem quite correct regarding the BSD lineage. Early MacOS X builds had more of a NetBSD lineage and that shifted to FreeBSD over time. Userland is closest to FreeBSD IIRC.
When Apple Dylan was cancelled, Dr Strassman went to work on online gaming. I exchanged one or two emails with him around that time, bemoaning the demise of that project (I still consider Dylan to be one of the best languages around). One of my friend at UCLA (Hi Scott !) used to know Steve from high-school.
I bought the Unix-Haters handbook then and agree with much of the spirit, despite the details being sometimes dated or missing the whole picture (probably on purpose). Despite that I work on Unix (and run OS X / FreeBSD / OpenBSD / Linux at home) and I prefer it to the alternatives I've seen so far.
Re:Not a good comparison
on
Gzip on a PCI card
·
· Score: 2, Interesting
If gzip -9 (a.k.a. gizp --best) is faster than gzip -1, it must be because you are IO limited, so writing a smaller file ends up as wall-clock saving.
It clearly is a flawed test to compare the CPU loads of -9 and -1 but it is an excellent example that IO is often the bottleneck.
Normally I don't mind RMS spouting off about something when he has a decent leg to stand on or is using his own forum. In this case, he really doesn't. The funny thing is that I typically dislike RMS, his political rants and the GPL (vs. really free, Artistic/MIT/BSD-like licences). In this case, however, I agree 100% with him. Bitkeeper's licence is crap.
It's too bad because it BK seems looks like a decent source control systems, something that is really missing for open-source projects. I haven't used subversion yet, but it is probably a better choice.
That's BS. Software design won't save you when you are modifying the makefiles, when you are touching a header file that is used everywhere, or when you have to do a clean build just to ensure that you won't screw up everybody simply because make is such a crappy/unreliable build tool. A good deal of the blame is also shared by C/C++ header files, which are a pretty antiquated way to specify an API.
Granted good software design should ensure that you don't have to do this often. However the typical build tools make it way too costly to fix such issues that force big recompiles. As a result they often remain unfixed.
I wish some vendor had the guts to promote a replacement for makefiles that would allow higher-level semantics to be exploited to reliably speed-up builds. Note: Apple is already doing good by promoting jam, even if jam is "just" a better make.
I had great hopes to see such a tool emerge from CodeSourcery's software carpentry contest. Too bad they didn't have the time to get to it.
I fully agree about the "Darwinism" comment. Not only application darwinism but also (mostly?) programmer Darwinism.
Basically this guy can't code a thread-safe app, doesn't understand the OS X history (hint: 10.2 lineage doesn't make its kernel "old"), can't code a debugger without/proc (hint: a lot of debuggers do without/proc), doesn't grok Cocoa, thinks that Powerplant is superior to Cocoa and C++ to Obj-C, etc.
I haven't used Pepper, but from the interview I'm glad I never had the opportunity.
Re:For those of us...
on
Serial ATA Coming
·
· Score: 2, Informative
But why are people posting such misinformation ?
IIRC, first generation SATA is a 1500Mb/s physical link, with a 8b/10b encoding (not so sure, look at the specs), so it would provide 1200Mb/s of effective bandwith, 150MB.
From what I've heard, SATA II would double the signaling rate, among other niceties, and there are already plans for 3rd generation signaling rate.
Slashdot Mirror
One good (very long) article on submarine cables (by Neal Stephenson):
Mother Earth Mother Board
It basically answers all the questions you had in your post. I had noted this article when it appeared and only got to reading it a month ago. A bit too verbose for my taste, but worth the time nonetheless.
the very long instruction pipelines on Itanium
Itanium2 has probably the shortest pipeline of any processor running at or above 1Ghz (can't remember if it's 7,8 or 9 stages). So much for very long instruction pipelines.
You probably misunderstood "very long instruction words" for very long pipeline. And Itanium isn't even a VLIW processor, although it was inspired by VLIW. If you complain about that, you could also complain about the Power4 instruction group mechanism.
Actually, the very long instruction pipelines on Itanium make it inefficient for systems with large numbers of processors.
:-). Check the SpecJBB scores someday (where a 32way Itanium system beats a 64way Sun, same result for 64way vs. 106way). Or maybe the TPC-H scores ? Or any other benchmark where you can compare high-end Sparcs versus high-end Itanium systems.
Ahahaha
You'll also see that Sun isn't publishing numbers for some of those benchmarks (TPC-C for example). Do you really believe that it's because of flaws in the benchmark ?
Let's compare:
SPARC at 1.2GHz has SpecINT of 642 and SpecFP of 953.
HP Integrity Server rx2600 (1500 MHz, Itanium 2) SpecINT 1322 SpecFP 2119
Ouch more than twice the performance at 25% higher frequency (and without Sun's SpecINT compiler cheat). As far as scalability go, a Superdome 32 processor beats a 74way Sun on SpecJBB (while the 64way Superdome beats the 106 way Sun). Solaris isn't the only game in town when it comes to scaling, and you don't always need the same scaling when each processor performs well.
Xeons are not 64-bit CPUs
Ah but Itanium CPUs are, you might want to compare Sparc processors against high-end processors. Now if you want to compare price/performance, sure, feel free to include Xeons and Opterons too.
The SPARC architecture will always outperform an Intel architecgture, even at 1/100 of the clock speed.
How can you be so deluded ? Are you a Solaris sysadmin in denial ? A Sun employee ?
You might want to check Spec CPU, TPC-C, TPC-H, SpecWeb, SpecSSL, Linpack, SAP benchmarks someday (I am probably forgetting some). And remember that Sun is cheating as much (or more, cf. their controversial Spec CPU optimizations) as the other vendors, so don't come back complaining about benchmarketing.
Also note that the competition isn't always a Xeon processor running Linux.
If these people (or Brad) were thinking at all toward the future they would have made the cards BIGGER not smaller.
...).
My understanding is that the PCI-Express folks are working on a cartridge standard for "full size" cards (think PCI-card level functionality). This may come with the 2nd generation signaling rate (up from the 1st generation 2.5 Gb/s/lane).
The goal is to allow users to add/remove cards from desktops/servers without having to open them (or even without having to shut them down). This should make card manufacturers smile, I know quite a few people who don't upgrade their PCI cards simply because they are scared of opening them.
I expect the typical 2008 full-size desktop to have one or two cartridge slots and a few ExpressCard slots. The cartridge slots would be used for power/space-hungry applications (Video, multi-IO cards, optical connections, solid-state disks), while the card slots would be available for other extensions (smart card reader, UWB adapter cards, FW 1.6 adapters,
Pins ? I don't see pins. Where do you see pins ? IIRC this is a beam connector with low contact counts. The connector carries power(s) + 1 USB 2.0 connection (480 Mb/s) + 1 PCI-Express 1x connection (2.5 Gb/s) + 1 management connection.
Why USB seems obvious to me. For some applications a 1x PCI-Express connection is going to be overkill. Think smart card readers (how many bits/s ?), modems, serial adapters (e.g. to get data from older equipment like a weather station, to slide projectors, home automation equipment, etc). Heck, USB 1.1 would be enough (or already too much). USB2 is today's equivalent of a cheap RS232 connection. When it's enough, it's enough. You do not always need 2.5 Gb/s :-)
Firewire doesn't make much sense as an internal connection. Too much overhead in the protocols employed, too many transistors required to get the base functionality. Please don't get me wrong, I love FW, I am not victim of USB 2 performance claims and I want to see 1394b connectors on every machine.
I don't blame you for your reaction though. When I first heard about the USB part of the spec I had the exact same reaction. However I had the chance to discuss this with some of the folks working on this specification. I now see why it makes sense.
I am afraid the release notes are a bit misleading.
The HW acceleration in 1.3.1 and in 1.4.1 are different beasts. 1.4.1 uses Quartz Extreme acceleration (layers/compositing), while 1.3.1 was accelerating 2D drawing (and adding visual glitches in the process).
If you follow the java-dev mailing lists, you would see posts from Apple employees mentionning that they intend to bring back the HW acceleration for 2D drawing (IIRC Gerard Ziemski said that recently).
FYI, the parent post appears to have been posted by Mike Paquette, who designed/wrote a good part of Quartz. His post is more than "+5 Informative", it should be "+10 Reference".
See a previous post of mine for references to Usenet posts from Mr. Paquette.
Apple's OSX does all rendering through Quartz, (as PDFs) which is accelerated by OpenGL, and called QuartzExtreme.
:-)
That's not accurate. Quartz is really made of two parts: Quartz 2D and the Quartz Compositor.
The Quartz Compositor is reponsible for compositing all the layers (desktop, windows, layers inside windows) on-screen. It offers Porter-Duff compositing, which was developped at Pixar more than 15 years ago. See this post from Mike Paquette for details. Mr Paquette is one of the main developpers of Quartz. Quartz Extreme is "simply" an OpenGL implementation of Porter-Duff compositing and modern graphic cards offer the primitives needed to do that very efficiently.
The Quartz 2D layer is what offers drawing primitives following the Postscript drawing model. The same drawing model is used with PDF (no surprise), Java2D and SVG (and Microsoft's GDI+ ?). This part is not HW accelerated. I am sure Apple is working on it, but it wouldn't surprise me if new HW will be required to make this possible. There is a strong incentive for card manufacturers to offer acceleration, since Longhorn is supposed to use GDI+ extensively. I doubt that such acceleration will fit in the traditionnal OpenGL/Direct3D rendering pipeline.
The Apple JVM team implemented HW accelerated Java2D drawing in their 1.3.1 JVM. Their 1.4 JVM doesn't offer it (1.4.1 was a massive rewrite for them, 1.3.1 was more of a quick port to OS-X using some of their "old" carbon code). There were quite a few problems when HW acceleration was used. I hope they can and will wait for a system-wide Quartz-2D HW acceleration, it seems ludicrous to have the JVM team spend resources on an effort that will be wasted once Quartz2D is accelerated.
See Apple Marketing page, another post from Mike Paquette, and the presentation from Apple at SIGgraph about Quartz Extreme and OpenGL.
If that post doesn't end-up rated +5 informative, I don't know what will !
In a talk at UCLA a few years back, a professor mentionned that the "isolation" doesn't work so well in practice. It turns out that even using different languages and different programming teams, there are always bugs that end-up in all versions.
There are many ways for an OS to be "a 64-bit OS". However programmers/users of existing 64bits OSes will typically check a single criterion, which is unlikely to be met by OS X 10.3 .
...) can make use of memory beyond the 4GB limit by using specific APIs that work around the 32bits pointers limitation. I hope that Panther will allow that.
1. An OS could be called "64bits OS" because it allows programs running on the computer to use 64bits-instructions, while leaving them with 32bits pointers. This is typically done by offering a 64bits datatype (int64_t/uint64_t in C99 compliant environments) and a compiler that will emit the right instruction sequences. It also requires that the underlying OS will be made somehow "64bits aware", ie that it will save/restore the full 64bits content of processor registers on context switches. My understanding is that Panther/10.3 will allow that, or at least most of that.
2. An OS could be called "64bits OS" because parts of the kernel (VM / buffer cache,
3. An OS could be called "64bits OS" because it allows the usage of more than 4GB of memory by all userland processes, while any given process is still limited to 4GB (32 bits pointers). My understanding is that Panther will do that.
4. An OS could be called "64bits OS" because the kernel code is compiled to follow a 64bits ABI (Application Binary Interface). In such an ABI, pointers are 64bits entities and some integer types are also 64bits. While an ABI covers _a lot more_ ground than just the size of the common C types, those sizes are often used to characterize the ABI. The most common 64bits ABI is known as LP64 (aka I32LP64) where "int" remain 32bits, while "long" and "void*" are 64bits. By comparison the most common 32bits ABI is known as ILP32 (int, long, void* are all 32 bits). I don't think any "common" OS offered a ILP64 model (Cray maybe?). Windows64 is a different beast, being LLP64 (aka IL32 LLP64), where int and long are 32bits, while "long long" and pointers are 64bits. My understanding is that this will _not_ be the case for Panther, the kernel code will be compiled with a ILP32 ABI.
5. An OS could be called "64bits OS" because it offers a 64bits ABI to userland applications compiled in "64bit mode". My understanding is that this will _not_ be the case for Panther, all code will be compiled with the traditional ILP32 ABI.
My "belief"/"understanding" of the Panther situation comes from reading the WWDC reports, rumours reports and also the Darwin development mailing list where one Apple employee said that OS X won't offer an LP64 ABI until much later (not in Panther, at _least_ not in 10.3.0 and I doubt any 10.3.x release).
Most current users of 64bits systems will only use criterion 5, but I expect Apple PR to try to muddle the issue. And I won't blame them much, the issue is not as clear cut as some users think.
Some tidbits related to 64bits platforms:
- HP-UX 11.00 shipped as two different kernels, one 32bits kernel and one 64bits kernel. 64bits machines could run either of them, while 32bits machines were restricted to the 32bits kernel.
On the 64bits kernel a user could run 32 and/or 64bits processes, while the 32bit kernel could only run 32bits processes.
It sometimes made sense for the owner of a 64bits machine to only install the 32bits kernel, if they didn't intend to run any 64bits application and didn't have more than 4GB of ram (rare then). Running the 64bits kernel typically consumed a bit more memory and consumed a bit more memory bandwidth.
- Linux on 64bits machines is "pure" 64bits (today, this may change due to ISV pressure). It doesn't run anything but programs compiled with the 64bits ABI (I32LP64). A special case is Linux IPF (IA64) which also runs 32bits apps, but those aren't "native" applications using the Itanium ISA but x86 binaries running using the hardware (now) or software (future) emulation. Another special case will be Linux on x86-64 which also has to run "emulat
What you are describing isn't benchmarking, it's stress testing.
e r-won't-matter.
Benchmarks are meant to predict performance. While it is essential to check the validity of the answer (wrong answers can be computed infinitely fast), the role of a benchmark isn't to check never-seen-in-practice cases or so-rarely-seen-in-practice-that-running-100x-slow
That reminds me of the "graphic benchmark" used by some Mac websites that compares Quickdraw/Quartz performance when creating 10k windows. Guess what, Quartz is slower, because Quartz windows are a lot more powerful/heavyweight than Quickdraw ones. But who gives a fuck, how often do you need to create 10k windows in a hurry ? No one, apart from those OS 9 zealots who are looking for ways to bash OS X. A realistic benchmark may to check to at most 10s of windows, but the conclusion would probably be that the difference in speed isn't observable by humans.
A good benchmark can only be judged by comparing its execution profile against what users will run. If it's not reflecting the reality, it's not an appropriate prediction of the performance for the user. And it's not a binary property. While Spec is by definition perfect for anyone that only runs Spec, it is known and accepted to be imperfect at anything else, and a completely useless predictor in some cases (as in very low statistical correlation between Spec scores and speed at running Foo). It's just a "best effort" suite of tests for workstation applications. I'm talking SpecINT / SpecFP here, other Spec benchmarks exist because (gasp!) SpecINT/FP don't cover the whole computing spectrum.
You also don't seem to have much of a clue about how processors are really tested. Guess what, the processors people do all that you describe and more, much more. All day long on many, many samples, for months on end, in good/bad conditions (thermal, electrical). It's just that no test suite can catch all the problems, so defects will always slip by. _Always_, even if the logic is formally proven correct, since processors aren't mathematical entities but subject to electrical / manufacturing variations. Even if no problem exists today on a given CPU, take a hundred of them from various batches, power-cycle them a few million times, run them for a few years in marginal conditions and check again.
There is one non-backward compatible change I'd like to see embraced: put the optical media in a _thin_ cartridge.
:(
I believe blue-ray is such, but from what I read blue-ray is not really meant as the next-gen DVD format, mostly as a format for recorders and computers. And one of the reason cited is the cartridge
I would prefer a format where the media is protected better than current CDs and DVDs. A format that could be grabbed by a reader more reliably than the current (cf. slot-loading readers on Mac). I don't understand why so many seem opposed to such a change. Maybe some people imagine something similar to the old CD caddies, where you had to place the regular format in a cartridge. I rather imagine a format that is always enclosed in a cartridge, like the 3 1/2" floppies.
Conspiracy theory: RIAA/MPAA execs don't want this to happen, as they know more people would lend their CDs/DVDs to friends if the media was made more resistant to abuse.
For the record: I don't believe that for a second.
No, Mac OS X does _not_ allow for multiple servers in the Mach 3 sense.
Darwin is a monolithic kernel where BSD is wedded to the Mach services (bound, not semi-bound). Cocoa and Carbon are purely user-space entities. Classic does have some support in the kernel but it is _not_ a server in the Mach sense, and it is also mostly a user-space thing.
From following the Darwin mailing lists, you seem quite correct regarding the BSD lineage. Early MacOS X builds had more of a NetBSD lineage and that shifted to FreeBSD over time. Userland is closest to FreeBSD IIRC.
Hopefully this post won't require a correction^3.
A lot of the issues in the book have a solution, and its name is "Perl"
:-)
Oh boy, if Perl is the solution, please, please don't expose me to the problem !
It's Steve Strassman (a.k.a. Strass), found here.
When Apple Dylan was cancelled, Dr Strassman went to work on online gaming. I exchanged one or two emails with him around that time, bemoaning the demise of that project (I still consider Dylan to be one of the best languages around). One of my friend at UCLA (Hi Scott !) used to know Steve from high-school.
I bought the Unix-Haters handbook then and agree with much of the spirit, despite the details being sometimes dated or missing the whole picture (probably on purpose). Despite that I work on Unix (and run OS X / FreeBSD / OpenBSD / Linux at home) and I prefer it to the alternatives I've seen so far.
If gzip -9 (a.k.a. gizp --best) is faster than gzip -1, it must be because you are IO limited, so writing a smaller file ends up as wall-clock saving.
It clearly is a flawed test to compare the CPU loads of -9 and -1 but it is an excellent example that IO is often the bottleneck.
Those 2 guys are well-known cranks. I can't believe they managed to make it into a "serious" newspaper.
:-(
They are "famous" in France as they presented some Sci-Fi TV show when I was growing-up. They have gone downhill from there
Normally I don't mind RMS spouting off about something when he has a decent leg to stand on or is using his own forum. In this case, he really doesn't.
The funny thing is that I typically dislike RMS, his political rants and the GPL (vs. really free, Artistic/MIT/BSD-like licences). In this case, however, I agree 100% with him. Bitkeeper's licence is crap.
It's too bad because it BK seems looks like a decent source control systems, something that is really missing for open-source projects. I haven't used subversion yet, but it is probably a better choice.
That's BS. Software design won't save you when you are modifying the makefiles, when you are touching a header file that is used everywhere, or when you have to do a clean build just to ensure that you won't screw up everybody simply because make is such a crappy/unreliable build tool. A good deal of the blame is also shared by C/C++ header files, which are a pretty antiquated way to specify an API.
Granted good software design should ensure that you don't have to do this often. However the typical build tools make it way too costly to fix such issues that force big recompiles. As a result they often remain unfixed.
I wish some vendor had the guts to promote a replacement for makefiles that would allow higher-level semantics to be exploited to reliably speed-up builds. Note: Apple is already doing good by promoting jam, even if jam is "just" a better make.
I had great hopes to see such a tool emerge from CodeSourcery's software carpentry contest. Too bad they didn't have the time to get to it.
I fully agree about the "Darwinism" comment. Not only application darwinism but also (mostly?) programmer Darwinism.
/proc (hint: a lot of debuggers do without /proc), doesn't grok Cocoa, thinks that Powerplant is superior to Cocoa and C++ to Obj-C, etc.
Basically this guy can't code a thread-safe app, doesn't understand the OS X history (hint: 10.2 lineage doesn't make its kernel "old"), can't code a debugger without
I haven't used Pepper, but from the interview I'm glad I never had the opportunity.
IIRC, first generation SATA is a 1500Mb/s physical link, with a 8b/10b encoding (not so sure, look at the specs), so it would provide 1200Mb/s of effective bandwith, 150MB.
From what I've heard, SATA II would double the signaling rate, among other niceties, and there are already plans for 3rd generation signaling rate.
Note: I am not complaining about the standard, but about the article.