It appears that this time Microsoft has essentially made the same mistake with the 360.
I don't think so. Microsoft has their stamp all over the hardware this time. Microsoft owns their variant of PowerPC and graphics card as much as Sony owns theirs. Looking at the initial hardware costs is deceiving. If you remember, the Playstation 2 sold for a huge loss in the beginning too. It was only later that they optimized production to the point that they were making profit off the system itself.
But LaserDiscs and LaserDisc players were inherently expensive to produce. Not even when DVD had nearly killed it had the price dropped. It wasn't simply an issue of demand. Nobody buys DVD recorder units, yet the price of them has gone below $250. The same will be true of BluRay and HD-DVD players. It won't be long before they're cheap and people will buy them.
Also, people needed their VHS recorders to record stuff. LaserDisc couldn't record so it could never replace VHS. DVS couldn't either for a long time. But then came ReplayTV and Tivo. Cheap satellite receivers come with built in PVRs, and cable companies are putting them out too in their receivers. A BluRay or HD-DVD player can fully replace a DVD player and be compatible.
And now that tons of people are actually buying DVD videos, the broadcast companies will have incentive in putting out BluRay or HD-DVD versions. Consider how many different versions of Terminator 2 on DVD have sold.
That still doesn't answer my question though.. where's the proof?
Why don't you go read the KHTML code and Apple's patches and decide for yourself? That's the only way you're going to get proof.
Re:Just speed up the GUI for christ's sake...
on
10.4 on Display at FOSE
·
· Score: 4, Informative
They did. Tiger introduces Quartz 2D Extreme. You just need a card that with fragment and vertex shading (aka DirectX 9 capable in the Windows world). Information about it here:
yum and up2date are crap. On FC3, they rotate through *all* mirrors, even mirrors that are in far off parts of the world. (You can hard code mirrors but you have find them). When a download of an rpm hangs up, you have to kill the process and restart. When you restart, they redownload all the rpms all over again. yum has no GUI. up2date has a GUI but it only lets you update rpms not install anything new. You have to use "Add/Remove Programs" in FC3 which will install the old version off your CD-ROM. Then you can update it. There are a couple attempts at GUIs around yum but they suck. The best is yum extender. The UI hangs when yum hangs. The yum output is in the last tab so if you don't switch to that tab before yum hangs, you won't be able to Ctrl-C yum to abort a download.
I've given up on yum and up2date and switched to apt and synaptic on FC3. Works like a dream. Mirrors can be set up within a CLI for apt. The synaptic GUI is excellent. Fedora semi-officially maintains the apt database but the apt database is always the last to be updated when rpms are updated.
yum and up2date existence is very questionable. They're fundamentally designed around the idea that no new packages will ever get added to the distribution after release. But the Fedora team has a religious attachment to yum so things will continue to suck for new users.
Absolutely, but you can see from the rest of my post that I wasn't trying to be critical of Quartz Extreme. I just wanted to acknowledge the difference between it and Avalon to be fair to Microsoft.
I was pointing out that Quartz Extreme was released 2 years ago, while Longhorn won't be released for another 2 years. Yet somehow people disregard this important fact. Microsoft has told us what they expect to have in 2006, but Apple has *not*. This has led many people here to the assumption that Apple will not have implemented equivalent capability by 2006.
Obviously, that's a silly assumption. If Quartz Extreme existed in a real product before Microsoft even announced Avalon, wouldn't it be more likely that Apple has actually extended 3D acceleration to other parts of the system in the meantime? And perhaps they don't want to risk talking about a technology unless they're sure it will make it into the next release? After all, we only just found out about features in next years's Mac OS X along with a preview version with stuff that actually worked.
So what will Apple have ready in 2006 when Longhorn is supposed to ship? Whoever answers that question is going to get sued for breach of NDA! Speaking of which, I probably should shut up now!
Longhorn's Avalon definitely goes beyond 10.2's Quartz Extreme. Quartz Extreme only 3D accelerates Quartz Compositor. Quartz 2D is still pure 2D. But for the record, it should be pointed out that that 10.2 is 2 years old while Longhorn won't be out for at least 2 years. The difference between Apple and Microsoft is that Microsoft boldly brags about features far in advance while Apple is highly secretive. A lot of people seem to think that Microsoft is overtaking Apple with Avalon, simply because Apple has only been publicly talking about their old Quartz Extreme technology. The reality is quite different. 3D acceleration for Quartz 2D may be ready in 10.4 next year.
OSX used to be leet, but 'sadly' it's being tailed with Longhorn, very fast indeed.
Utter nonsense. Microsoft tells you all the things they're doing for Longhorn way ahead of time. So far in advance that some of those features get pushed back to later releases when they realize they can't get it down. And Longhorn is getting released when? 2006 at earliest?
How much of what was announced at Apple's WWDC for Tiger (due out in 2005) did you know about ahead of time? Apple handed out preview releases with features no one knew they were working on. Apple's website only covers the features that are stable and useable in that preview release. Meaning there's more stuff which only WWDC 2004 members heard about and aren't allowed to talk about.
Quartz Extreme is Mac OS 10.2 technology. (And when did you first hear about that?) 10.3 brought Quartz 2D on OpenGL. It lets you use parts of Quartz 2D inside OpenGL canvases. At last year's WWDC they said they needed fragment and vertex shading support to get all the widgets implemented in OpenGL. As a result, Quartz 2D on OpenGL isn't something that happens automatically on Panther. You could utilize Quartz 2D objects like fonts inside your own OpenGL programs. So what will 10.4 bring? Suffice to say that Apple is not standing still. Complete 3D acceleration of the GUI has pretty clearly been in their roadmap. They've had a head start over Microsoft and are likely to stay ahead.
When you switch contexts, your virtually addressed cache and TLB are meaningless.
Correction, I should have said that your virtual addressed TLB and the (physically addressed) cache have no values meaningful values for the next thread/process that is context switched in. The TLB gets flushed and the cache will be overwritten. So you hit main memory quite a bit on context switches. It's very very wasteful.
Anyway it's not that simple - lot of stuff isn't memory bandwidth starved. And the "often faster" is quite subjective;).
You're missing the point. I'm not talking about memory bandwidth, I'm talking about memory latency. Very few programs have any natural need for a lot of memory bandwidth. What they do want is low memory latency. But there's a fundamental problem: CPU performance increases outpace memory performance increases. Most programs, most of the time, are waiting for a memory access to complete. The direction you take on a conditional branch often depends on the result of memory access. There's branch prediction, value prediction, and all that but they can only go so far. They don't work well enough to keep CPUs occupied. The goal is to let a CPU do other things while waiting for a memory access to complete. The benefit of SMP and SMT is that you're working with 2 threads each with separate stacks and registers. If you imagine the simple case where your memory controller can only handle one memory access at a time, one thread can do its computation while another waits for the memory access. The other thing you need to consider is context switching. When you switch contexts, your virtually addressed cache and TLB are meaningless. You have to save your registers. That takes a hell of a lot of time because it's completely a memory latency bound operation.
I also never said that Sun's claims on UltraSPARC IV performance should be accepted at face value. They all cheat. But the one thing you won't hear claimed is that they'll get double the performance by doubling the clock rate. That's too easy to disprove. If that was possible, Intel wouldn't even be screwing around with EPIC and dual core.
And obviously, if code isn't multithreaded with few accesses to shared memory then that program won't run any faster. But nowadays people run multiple programs at once, and like having good response time when switching between them. However, that improvement is hard to quantify and it has really prevented SMP from going mainstream earlier.
Aaaand I quote (from your own grandparent comment):
A dual CPU configuration is often faster than a single CPU that's twice as fast.
No mention of clock rates there.
My mistake, that was what I meant but I did a bad job of writing it. No doubt, getting double or more of the performance by adding a second CPU is absurd. But being able to do better than a clock rate double is something that we can expect with a good dual processor implementation when software is parallelized. Sun recently claimed a 1.8 times performance boost with the dual core UltraSparc IV over the same clock rate single core UltraSparc III. A clock doubling offers much less than double the performance because of the bottleneck that is main memory latency.
Actually, a dual CPU configuration is rarely twice as fast as a single CPU that's twice as fast.
This was a typo, right? Because I said 2 CPUs were often faster than 1 CPU running at twice the clock rate, not that it was twice as fast. I admit that "often faster" was overstating it. It really depends on how parallel and I/O bound your workload is. The responsiveness of a dual processor system can be better than a single processor system because there will be half as many wasteful context switches per CPU.
Especially not in shared-bus architectures like the P4. Or the dual-core P4/AMD64 CPUs, which will share a memory bus.
Yes, the P4 has a terrible multiprocessor bus architecture as do all Pentium processors. But that's because Intel didn't care. The standard Microsoft operating system for the desktops (Windows 9x) never supported multiple processors so there wasn't much incentive for Intel to optimize their bus for it. The AMD64's bus is far superior, and so is the PowerPC's.
And for a dual core, the interprocessor bandwidth will be much higher and the latency much less. Cache coherence is handled on die. The dual core Opteron will still have 2 distinct L2s. But they won't have to go off chip to maintain coherence between each other. There's no HyperTransport latency for snooping between L2s on the same die. And the off chip (HT) latency will be the same for dual core as it is for a single core.
SMP will be mainstream very soon. You already need SMP support to use Hyperthreading/SMT. All recent Pentium 4's are 2-way hyperthreaded: so 2 logical processors. 2 sets of registers with shared functional units and cache.
Intel and AMD will be coming out with dual core CPUs by the end of next year: 2 CPUs in one chip with a very speed interconnect between the two. A dual CPU configuration is often faster than a single CPU that's twice as fast. (On the other hand, Hyperthreading gives a measly 30% at most). A dual core Pentium series processor would have 2 real processors each with 2 logical processors: so a quad processor. Once all new computers have at least 2 processors in them, the operating systems that can utilize them effectively will be have a significant advantage.
Because as nice as the thought of OS X is:
* The price of the hardware is too much to stomach.
A little while ago I would have agreed with you. I've been building PCs for over 10 years now and have gotten proficient at finding out what's the hot motherboard, CPU, and graphics card of the day. But there are some things about hardware configurations that you never find out until its too late.
For example, I've been through 3 Athlon motherboards now. The first was an Asus AMD760 based one which I used with my GeForce 2 GTS. Plenty of BSODs related to the Nvidia driver that only plagued Athlon users. No one had any idea why. I switched to an Asus KT266A motherboard because VIA at least seemed to be trying to do something about the problem. Then someone went and actually measured the amount of current going to the DIMMs with a system with an Athlon rated power supply. The memory was only getting half the required current. People were selling 300W power supplies claiming that they were good enough for an Athlon. But they rarely were. But Intel set things straight for the P4. A "Pentium 4" rated power supply (>=435W) was something you could mostly trust to satisfy an Athlon. So I upgraded my power supply.
Things were fine for a while until I wanted to add more memory. So I bought another stick to compliment the two already in there. Then I found out that my motherboard chokes when all 3 RAM banks were filled. Others knew about the hardware bug but there was no solution. Asus had no interest in fixing the problem. The motherboard was already 2 years old by then. But I couldn't return the RAM because it took me a few weeks to track the problem down.
So I upgraded to an Nforce 2. The memory now worked and I even managed to get dual channel out of 3 chips, but I found out that Nvidia's USB controller was crap. It didn't recognize my joystick. So I had to buy a 2 port USB card. The onboard Serial ATA chipset made by Silicon Image has been declared broken by the Linux community. Forunately I wasn't brave enough to get a Serial ATA drive.
None of those problems would happen on the Mac. Apple actually does real testing on their hardware. PC hardware has just gotten more unreliable. Prices have dropped since we're buying all motherboards and chipsets from overseas. But when you put these parts together you get something that all these venders weasle out of supporting. It's not surprising that there's going to be crap hardware out there. But it is surprising when it's the hardware that wins awards on all the geek sites.
* The price of the software is often more expensive for Mac than it is for IBM-PC compats.
* There is far worse interoperability from a hardware standpoint.
But topic is about switching to Linux. Linux users don't even have that software to buy. And Linux hardware support is bad. There may be a greater number of pieces of hardware that "sort of" work on Linux, but the core components are never as well supported as they are for the Mac. Apple has the best OpenGL implementations for Nvidia and ATI cards and they use it far more aggressively than anyone else. They invest in LCD research and so always get first dibs on the most advanced displays. Tiger will have the fastest video performance by far because CoreVideo is 3D accelerated using pixel shading. They've overtaken Microsoft by years. We've tapped out what a single CPU can do. Programmable hardware is the future. Games have fueled its development on the video card. But its utility extends beyond games. Anything that involves parallel processing will benefit from auxilliary array processing units. The hardware to do it is cheap but the operating system needs to use it automatically.
Quit with the "why not run Mac?" crap. Since computers have become commodities, it's not going to happen. What needs to happen is, people need to embrace the idea that it's software that is fast becoming a commodity.
You claim that software is becoming a commodity. But I think that perception is
I guess NeXTStep/OpenStep are similar, in that all of them use DisplayPostscript. Sun was considering switching to OpenStep at one point in time. MacOS X (OpenStep 5, sort of?) uses DisplayPDF. And Keith Packard is working on a DisplayPostscript-like extension for X called Cairo.
Are you claiming that MS helped design the x86-64 ISA? That's just silly. There aren't any processor architects at MS (probably 'cause they don't make processors) so there really isn't much they could have contributed.
Wrong. Processor architects aren't the ones who invent ISAs. An ISA is merely the application and operating system level interface to a processor. A processor designer is someone who figures out to implement an ISA efficiently.
It's actually compiler designers who come up with new instruction set architectures. IA64 wasn't designed by Intel. It was designed by an HP compiler designer who himself came from an unsuccessful company he founded called Multiflow. He developed some very influential compiler technology for parallelizing execution. He then developed a new type of processor architecture called VLIW that he believed would work optimally with his compiler technology. But Multiflow failed miserably. People were able to use the same technology on superscalar processors.
RISC comes from Patterson and Hennessy who both were compiler designers. They found that a load-store architecture was easy to write an optimal compiler for. And since by then nearly everyone was using compiled languages like C, what was best for the compiler was best for the application programmer.
The entire success of Itanium is based on whether compilers can schedule code better than a processor can. It was because some compiler people thought they could do it that the architecture even exists. So Microsoft, being a compiler and operating system maker, *does* have a hell of a lot to say about this.
The XFree86 people have been working with RMS. It's not the end of the world yet. My understanding is that the license changes only affect the XFree86 server code. The understand that they can't change the license on the X libraries willy-nilly. And we only link against the X library code so all is well.
But the Freeware CD is not going to be enough anymore. Once GNOME is integrated into Solaris, Sun won't be able to keep the GNU stuff separate. They need to address the incompatibility. And they need to make it easy for GNOME developers to test software on Solaris. They won't be able to afford Sun's compiler, so Sun should ensure that GCC remains compatible. As for the ABI, the C ABI really was supposed to be stable. When basic things like Zlib and GTK+ libraries are incompatible, you either have a choice of using Sun's GNOME distribution with Sun's compiler, or to throw it all out and rebuild everything with GCC. Once GNOME is integrated, you probably can't just throw it all out.
I agree that the Sun C/C++ compiler is very good. But gcc is here to stay. If Sun is serious about adopting GNOME as their user interface, then they need to accept everything that comes with it. GNOME software is community developed, and the developers will not test the software on Solaris with Sun's compiler. They will only use gcc because it is free software. It is not tractable for Sun to do all the work verifying that each GNOME package compiles and operates with Sun's compiler. And it is not acceptable to assume that every Solaris developer will use Sun's compiler.
Sun's needs to do what other UNIX vendors have done. Actively provide fixes and performance improvements for GCC and do what's necessary to ensure binary compatibility. I'm not saying that Sun needs to break their own released ABIs, they could instead work to change GCC so that it becomes compatible with theirs. GCC users are already used to evolving ABIs. It would be worth it for Solaris GCC users.
I'm still trying to compile GNOME on Solaris *as* a root user. It's been a year now. Not done yet. Seriously. I wasted a lot of time trying to get that OpenJade crap working. I couldn't figure out why OpenJade would crash every time I ran it. It was only months later that I found out that a shared library version of OpenSP doesn't work on Solaris. The Openjade people didn't think it important enough to mention. But even after getting that stuff built and figuring out how to install DTDs by looking at my Linux system, it still wouldn't work. So then there was no choice but to disable all gnome doc building.
And then there's that goddamn gettext/libintl stuff. I don't have the option of overriding the Sun version of libintl across the board by placing the GNU libintl in/usr/local. Our Solaris software that uses Sun's libintl will break. You think the GNU people could have at least made it possible to use a different library name (libgintl maybe) for their incompatible version of libintl and have their configure scripts search for that.
Now all my stuff is out of date so I have to start over from the beginning again. Building GNOME has just become a great way to procrastinate. I wonder if I'll ever get to KDE.
Sun tries to solve this problem by giving you a prepackaged version of GNOME. But 2 problems with their approach: 1) it's never up to date, and 2) it's only good if you have Sun's C compiler. I don't know how, but somehow Sun's GTK+ C library is incompatible with GCC's. Same with their Zlib. So I can't use Sun's GNOME distribution to write software. I though that kind of stuff was only supposed to happen with C++. I'd much rather like Sun to promote a/usr/ports like thing for Solaris. Whatever they did to get GNOME to compile they need to stick those patches in a/usr/ports. The community would help out. Then eventually we can have full "distributions" that we can install onto a Solaris system. Life would be a lot easier if there was something like "fink" in place for Solaris.
And while they're at it, Sun needs to stop ignoring GCC. Make the C and C++ ABI compatible. There are a lot of Solaris software houses that only use GCC because they need to build their code on other unices. They're not going to be able to use Sun's GNOME environment if it's not GCC compatible.
Well, the thing that always pissed me of is the gettext incompatibility. Unless I disable internationalization most GNOME packages will fail in configure. GNU added extra functions to their own gettext with GNOME requires. I wasn't able to upgrade to Solaris 8 when I did this so I couldn't try out Sun's new gettext library. I heard that the GNOME programs will still demand the GNU one installed.
The other thing is I can never get the Jade stuff to work. The Openjade people didn't bother to mention that trying to build openjade as a shared C++ library causes core dumps on linkage. And even after getting that stuff installed it still doesn't work.
I'm amazed that you managed to zip past those without "any problems".
Slashdot Mirror
and now I'm wondering why I ever left. That's it, I'm going back to the Slack *now*.
I don't think so. Microsoft has their stamp all over the hardware this time. Microsoft owns their variant of PowerPC and graphics card as much as Sony owns theirs. Looking at the initial hardware costs is deceiving. If you remember, the Playstation 2 sold for a huge loss in the beginning too. It was only later that they optimized production to the point that they were making profit off the system itself.
But LaserDiscs and LaserDisc players were inherently expensive to produce. Not even when DVD had nearly killed it had the price dropped. It wasn't simply an issue of demand. Nobody buys DVD recorder units, yet the price of them has gone below $250. The same will be true of BluRay and HD-DVD players. It won't be long before they're cheap and people will buy them.
Also, people needed their VHS recorders to record stuff. LaserDisc couldn't record so it could never replace VHS. DVS couldn't either for a long time. But then came ReplayTV and Tivo. Cheap satellite receivers come with built in PVRs, and cable companies are putting them out too in their receivers. A BluRay or HD-DVD player can fully replace a DVD player and be compatible.
And now that tons of people are actually buying DVD videos, the broadcast companies will have incentive in putting out BluRay or HD-DVD versions. Consider how many different versions of Terminator 2 on DVD have sold.
There were 45GB drives in the 75GXP series. All of mine died.
Why don't you go read the KHTML code and Apple's patches and decide for yourself? That's the only way you're going to get proof.
http://episteme.arstechnica.com/eve/ubb.x/a/tpc/f/ 8300945231/m/886008328631/r/886008328631/
And don't knock Spotlight until you've tried it. You don't like instantaneous searching?
yum and up2date are crap. On FC3, they rotate through *all* mirrors, even mirrors that are in far off parts of the world. (You can hard code mirrors but you have find them). When a download of an rpm hangs up, you have to kill the process and restart. When you restart, they redownload all the rpms all over again. yum has no GUI. up2date has a GUI but it only lets you update rpms not install anything new. You have to use "Add/Remove Programs" in FC3 which will install the old version off your CD-ROM. Then you can update it. There are a couple attempts at GUIs around yum but they suck. The best is yum extender. The UI hangs when yum hangs. The yum output is in the last tab so if you don't switch to that tab before yum hangs, you won't be able to Ctrl-C yum to abort a download.
I've given up on yum and up2date and switched to apt and synaptic on FC3. Works like a dream. Mirrors can be set up within a CLI for apt. The synaptic GUI is excellent. Fedora semi-officially maintains the apt database but the apt database is always the last to be updated when rpms are updated.
yum and up2date existence is very questionable. They're fundamentally designed around the idea that no new packages will ever get added to the distribution after release. But the Fedora team has a religious attachment to yum so things will continue to suck for new users.
Absolutely, but you can see from the rest of my post that I wasn't trying to be critical of Quartz Extreme. I just wanted to acknowledge the difference between it and Avalon to be fair to Microsoft.
I was pointing out that Quartz Extreme was released 2 years ago, while Longhorn won't be released for another 2 years. Yet somehow people disregard this important fact. Microsoft has told us what they expect to have in 2006, but Apple has *not*. This has led many people here to the assumption that Apple will not have implemented equivalent capability by 2006.
Obviously, that's a silly assumption. If Quartz Extreme existed in a real product before Microsoft even announced Avalon, wouldn't it be more likely that Apple has actually extended 3D acceleration to other parts of the system in the meantime? And perhaps they don't want to risk talking about a technology unless they're sure it will make it into the next release? After all, we only just found out about features in next years's Mac OS X along with a preview version with stuff that actually worked.
So what will Apple have ready in 2006 when Longhorn is supposed to ship? Whoever answers that question is going to get sued for breach of NDA! Speaking of which, I probably should shut up now!
Longhorn's Avalon definitely goes beyond 10.2's Quartz Extreme. Quartz Extreme only 3D accelerates Quartz Compositor. Quartz 2D is still pure 2D. But for the record, it should be pointed out that that 10.2 is 2 years old while Longhorn won't be out for at least 2 years. The difference between Apple and Microsoft is that Microsoft boldly brags about features far in advance while Apple is highly secretive. A lot of people seem to think that Microsoft is overtaking Apple with Avalon, simply because Apple has only been publicly talking about their old Quartz Extreme technology. The reality is quite different. 3D acceleration for Quartz 2D may be ready in 10.4 next year.
Utter nonsense. Microsoft tells you all the things they're doing for Longhorn way ahead of time. So far in advance that some of those features get pushed back to later releases when they realize they can't get it down. And Longhorn is getting released when? 2006 at earliest?
How much of what was announced at Apple's WWDC for Tiger (due out in 2005) did you know about ahead of time? Apple handed out preview releases with features no one knew they were working on. Apple's website only covers the features that are stable and useable in that preview release. Meaning there's more stuff which only WWDC 2004 members heard about and aren't allowed to talk about.
Quartz Extreme is Mac OS 10.2 technology. (And when did you first hear about that?) 10.3 brought Quartz 2D on OpenGL. It lets you use parts of Quartz 2D inside OpenGL canvases. At last year's WWDC they said they needed fragment and vertex shading support to get all the widgets implemented in OpenGL. As a result, Quartz 2D on OpenGL isn't something that happens automatically on Panther. You could utilize Quartz 2D objects like fonts inside your own OpenGL programs. So what will 10.4 bring? Suffice to say that Apple is not standing still. Complete 3D acceleration of the GUI has pretty clearly been in their roadmap. They've had a head start over Microsoft and are likely to stay ahead.
Correction, I should have said that your virtual addressed TLB and the (physically addressed) cache have no values meaningful values for the next thread/process that is context switched in. The TLB gets flushed and the cache will be overwritten. So you hit main memory quite a bit on context switches. It's very very wasteful.
You're missing the point. I'm not talking about memory bandwidth, I'm talking about memory latency. Very few programs have any natural need for a lot of memory bandwidth. What they do want is low memory latency. But there's a fundamental problem: CPU performance increases outpace memory performance increases. Most programs, most of the time, are waiting for a memory access to complete. The direction you take on a conditional branch often depends on the result of memory access. There's branch prediction, value prediction, and all that but they can only go so far. They don't work well enough to keep CPUs occupied. The goal is to let a CPU do other things while waiting for a memory access to complete. The benefit of SMP and SMT is that you're working with 2 threads each with separate stacks and registers. If you imagine the simple case where your memory controller can only handle one memory access at a time, one thread can do its computation while another waits for the memory access. The other thing you need to consider is context switching. When you switch contexts, your virtually addressed cache and TLB are meaningless. You have to save your registers. That takes a hell of a lot of time because it's completely a memory latency bound operation.
I also never said that Sun's claims on UltraSPARC IV performance should be accepted at face value. They all cheat. But the one thing you won't hear claimed is that they'll get double the performance by doubling the clock rate. That's too easy to disprove. If that was possible, Intel wouldn't even be screwing around with EPIC and dual core.
And obviously, if code isn't multithreaded with few accesses to shared memory then that program won't run any faster. But nowadays people run multiple programs at once, and like having good response time when switching between them. However, that improvement is hard to quantify and it has really prevented SMP from going mainstream earlier.
A dual CPU configuration is often faster than a single CPU that's twice as fast.
No mention of clock rates there.
My mistake, that was what I meant but I did a bad job of writing it. No doubt, getting double or more of the performance by adding a second CPU is absurd. But being able to do better than a clock rate double is something that we can expect with a good dual processor implementation when software is parallelized. Sun recently claimed a 1.8 times performance boost with the dual core UltraSparc IV over the same clock rate single core UltraSparc III. A clock doubling offers much less than double the performance because of the bottleneck that is main memory latency.
This was a typo, right? Because I said 2 CPUs were often faster than 1 CPU running at twice the clock rate, not that it was twice as fast. I admit that "often faster" was overstating it. It really depends on how parallel and I/O bound your workload is. The responsiveness of a dual processor system can be better than a single processor system because there will be half as many wasteful context switches per CPU.
Especially not in shared-bus architectures like the P4. Or the dual-core P4/AMD64 CPUs, which will share a memory bus.
Yes, the P4 has a terrible multiprocessor bus architecture as do all Pentium processors. But that's because Intel didn't care. The standard Microsoft operating system for the desktops (Windows 9x) never supported multiple processors so there wasn't much incentive for Intel to optimize their bus for it. The AMD64's bus is far superior, and so is the PowerPC's.
And for a dual core, the interprocessor bandwidth will be much higher and the latency much less. Cache coherence is handled on die. The dual core Opteron will still have 2 distinct L2s. But they won't have to go off chip to maintain coherence between each other. There's no HyperTransport latency for snooping between L2s on the same die. And the off chip (HT) latency will be the same for dual core as it is for a single core.
SMP will be mainstream very soon. You already need SMP support to use Hyperthreading/SMT. All recent Pentium 4's are 2-way hyperthreaded: so 2 logical processors. 2 sets of registers with shared functional units and cache.
Intel and AMD will be coming out with dual core CPUs by the end of next year: 2 CPUs in one chip with a very speed interconnect between the two. A dual CPU configuration is often faster than a single CPU that's twice as fast. (On the other hand, Hyperthreading gives a measly 30% at most). A dual core Pentium series processor would have 2 real processors each with 2 logical processors: so a quad processor. Once all new computers have at least 2 processors in them, the operating systems that can utilize them effectively will be have a significant advantage.
A little while ago I would have agreed with you. I've been building PCs for over 10 years now and have gotten proficient at finding out what's the hot motherboard, CPU, and graphics card of the day. But there are some things about hardware configurations that you never find out until its too late.
For example, I've been through 3 Athlon motherboards now. The first was an Asus AMD760 based one which I used with my GeForce 2 GTS. Plenty of BSODs related to the Nvidia driver that only plagued Athlon users. No one had any idea why. I switched to an Asus KT266A motherboard because VIA at least seemed to be trying to do something about the problem. Then someone went and actually measured the amount of current going to the DIMMs with a system with an Athlon rated power supply. The memory was only getting half the required current. People were selling 300W power supplies claiming that they were good enough for an Athlon. But they rarely were. But Intel set things straight for the P4. A "Pentium 4" rated power supply (>=435W) was something you could mostly trust to satisfy an Athlon. So I upgraded my power supply.
Things were fine for a while until I wanted to add more memory. So I bought another stick to compliment the two already in there. Then I found out that my motherboard chokes when all 3 RAM banks were filled. Others knew about the hardware bug but there was no solution. Asus had no interest in fixing the problem. The motherboard was already 2 years old by then. But I couldn't return the RAM because it took me a few weeks to track the problem down.
So I upgraded to an Nforce 2. The memory now worked and I even managed to get dual channel out of 3 chips, but I found out that Nvidia's USB controller was crap. It didn't recognize my joystick. So I had to buy a 2 port USB card. The onboard Serial ATA chipset made by Silicon Image has been declared broken by the Linux community. Forunately I wasn't brave enough to get a Serial ATA drive.
None of those problems would happen on the Mac. Apple actually does real testing on their hardware. PC hardware has just gotten more unreliable. Prices have dropped since we're buying all motherboards and chipsets from overseas. But when you put these parts together you get something that all these venders weasle out of supporting. It's not surprising that there's going to be crap hardware out there. But it is surprising when it's the hardware that wins awards on all the geek sites.
* The price of the software is often more expensive for Mac than it is for IBM-PC compats. * There is far worse interoperability from a hardware standpoint.
But topic is about switching to Linux. Linux users don't even have that software to buy. And Linux hardware support is bad. There may be a greater number of pieces of hardware that "sort of" work on Linux, but the core components are never as well supported as they are for the Mac. Apple has the best OpenGL implementations for Nvidia and ATI cards and they use it far more aggressively than anyone else. They invest in LCD research and so always get first dibs on the most advanced displays. Tiger will have the fastest video performance by far because CoreVideo is 3D accelerated using pixel shading. They've overtaken Microsoft by years. We've tapped out what a single CPU can do. Programmable hardware is the future. Games have fueled its development on the video card. But its utility extends beyond games. Anything that involves parallel processing will benefit from auxilliary array processing units. The hardware to do it is cheap but the operating system needs to use it automatically.
Quit with the "why not run Mac?" crap. Since computers have become commodities, it's not going to happen. What needs to happen is, people need to embrace the idea that it's software that is fast becoming a commodity.
You claim that software is becoming a commodity. But I think that perception is
I guess NeXTStep/OpenStep are similar, in that all of them use DisplayPostscript. Sun was considering switching to OpenStep at one point in time. MacOS X (OpenStep 5, sort of?) uses DisplayPDF. And Keith Packard is working on a DisplayPostscript-like extension for X called Cairo.
Lua's probably a better choice for game scripting. You can embed the interpretor easily into C/C++ and easily be able to call into C from Lua.
Wrong. Processor architects aren't the ones who invent ISAs. An ISA is merely the application and operating system level interface to a processor. A processor designer is someone who figures out to implement an ISA efficiently.
It's actually compiler designers who come up with new instruction set architectures. IA64 wasn't designed by Intel. It was designed by an HP compiler designer who himself came from an unsuccessful company he founded called Multiflow. He developed some very influential compiler technology for parallelizing execution. He then developed a new type of processor architecture called VLIW that he believed would work optimally with his compiler technology. But Multiflow failed miserably. People were able to use the same technology on superscalar processors.
RISC comes from Patterson and Hennessy who both were compiler designers. They found that a load-store architecture was easy to write an optimal compiler for. And since by then nearly everyone was using compiled languages like C, what was best for the compiler was best for the application programmer.
The entire success of Itanium is based on whether compilers can schedule code better than a processor can. It was because some compiler people thought they could do it that the architecture even exists. So Microsoft, being a compiler and operating system maker, *does* have a hell of a lot to say about this.
The XFree86 people have been working with RMS. It's not the end of the world yet. My understanding is that the license changes only affect the XFree86 server code. The understand that they can't change the license on the X libraries willy-nilly. And we only link against the X library code so all is well.
Thanks, pkgsrc looks really cool!
But the Freeware CD is not going to be enough anymore. Once GNOME is integrated into Solaris, Sun won't be able to keep the GNU stuff separate. They need to address the incompatibility. And they need to make it easy for GNOME developers to test software on Solaris. They won't be able to afford Sun's compiler, so Sun should ensure that GCC remains compatible. As for the ABI, the C ABI really was supposed to be stable. When basic things like Zlib and GTK+ libraries are incompatible, you either have a choice of using Sun's GNOME distribution with Sun's compiler, or to throw it all out and rebuild everything with GCC. Once GNOME is integrated, you probably can't just throw it all out.
I agree that the Sun C/C++ compiler is very good. But gcc is here to stay. If Sun is serious about adopting GNOME as their user interface, then they need to accept everything that comes with it. GNOME software is community developed, and the developers will not test the software on Solaris with Sun's compiler. They will only use gcc because it is free software. It is not tractable for Sun to do all the work verifying that each GNOME package compiles and operates with Sun's compiler. And it is not acceptable to assume that every Solaris developer will use Sun's compiler.
Sun's needs to do what other UNIX vendors have done. Actively provide fixes and performance improvements for GCC and do what's necessary to ensure binary compatibility. I'm not saying that Sun needs to break their own released ABIs, they could instead work to change GCC so that it becomes compatible with theirs. GCC users are already used to evolving ABIs. It would be worth it for Solaris GCC users.
I'm still trying to compile GNOME on Solaris *as* a root user. It's been a year now. Not done yet. Seriously. I wasted a lot of time trying to get that OpenJade crap working. I couldn't figure out why OpenJade would crash every time I ran it. It was only months later that I found out that a shared library version of OpenSP doesn't work on Solaris. The Openjade people didn't think it important enough to mention. But even after getting that stuff built and figuring out how to install DTDs by looking at my Linux system, it still wouldn't work. So then there was no choice but to disable all gnome doc building.
/usr/local. Our Solaris software that uses Sun's libintl will break. You think the GNU people could have at least made it possible to use a different library name (libgintl maybe) for their incompatible version of libintl and have their configure scripts search for that.
/usr/ports like thing for Solaris. Whatever they did to get GNOME to compile they need to stick those patches in a /usr/ports. The community would help out. Then eventually we can have full "distributions" that we can install onto a Solaris system. Life would be a lot easier if there was something like "fink" in place for Solaris.
And then there's that goddamn gettext/libintl stuff. I don't have the option of overriding the Sun version of libintl across the board by placing the GNU libintl in
Now all my stuff is out of date so I have to start over from the beginning again. Building GNOME has just become a great way to procrastinate. I wonder if I'll ever get to KDE.
Sun tries to solve this problem by giving you a prepackaged version of GNOME. But 2 problems with their approach: 1) it's never up to date, and 2) it's only good if you have Sun's C compiler. I don't know how, but somehow Sun's GTK+ C library is incompatible with GCC's. Same with their Zlib. So I can't use Sun's GNOME distribution to write software. I though that kind of stuff was only supposed to happen with C++. I'd much rather like Sun to promote a
And while they're at it, Sun needs to stop ignoring GCC. Make the C and C++ ABI compatible. There are a lot of Solaris software houses that only use GCC because they need to build their code on other unices. They're not going to be able to use Sun's GNOME environment if it's not GCC compatible.
Well, the thing that always pissed me of is the gettext incompatibility. Unless I disable internationalization most GNOME packages will fail in configure. GNU added extra functions to their own gettext with GNOME requires. I wasn't able to upgrade to Solaris 8 when I did this so I couldn't try out Sun's new gettext library. I heard that the GNOME programs will still demand the GNU one installed.
The other thing is I can never get the Jade stuff to work. The Openjade people didn't bother to mention that trying to build openjade as a shared C++ library causes core dumps on linkage. And even after getting that stuff installed it still doesn't work.
I'm amazed that you managed to zip past those without "any problems".