At a technical level, the difference between OOO and IO is thus: an OOO Processor can issue, via a structure called a reservation station, instructions in an order other than what is in the code stream. So say the CPU decodes instructions A, B, C, and D, in that order. These instructions go into a reservation station. Instructions in this structure sit there until all its source operands are available. That means if A, B, C, and D enter the RS, but B and C's operands are available before A and D's, B and C will execute before A and D.
The key use of OOO is two fold. First, it reduces the compiler's burder. Say the CPU is designed so the latency between two FPU additions is 4 clock cycles. With an in-order processor, the compiler would have to schedule code so there are 4 independent operations between each pair of dependent ones. If a dependent operation shows up in the code stream before the instruction it depends on has completed, the processor will just wait there while the instruction finishes, even if there are instructions in the queue behind the dependent one that could be executing in the mean time. In an OOO processor, if independent instructions arrive while a particular instruction is waiting for some operands, they'll be executed ahead of the waiting instruction.
The other use of OOO is to cover the latencies to caches and memory. Typically, L1 caches have a latency of 3 cycles, while L2 caches have latencies of 10-30 cycles, and memory has latencies of upwards of 150 cycles. If an instruction arrives that requires results from memory, it could be waiting anywhere from 3-150 cycles for that data to arrive, depending on what is cached. In an in-order processor, this could cause the CPU to stall for a very long time doing nothing, even when there are instructions behind the waiting one that could be executing in the meantime.
Oh really? Took me a minute (at most) todo this on konqueror.
I used to do that too (indeed, my layout looked almost exactly like that). Then I realized I had to do it over for every app. Or every time I tried a new distribution. Or whenever I had to wipe my.kde directory. Then I realized that GNOME looked exactly the way I wanted, out of the box. Moreover, GNOME's widget layouts are right, and its color coordination and useage of spacing is far superior to KDE's. These things may seem like small details, but make the UI much less tiring to use over a long period of time.
I really like the customisability of KDE applications, one of the reason why I use KDE in particular. I like having access to advanced tools if I need it. I'd rather not have a dumbed down UI.
The thing about customizability is this: its usually a bad thing. The way people want to work is usually not the way they should be working. This is a fact in many facets of life --- that's precisely why every industry you'll encounter has "best practices" to teach you how you should be doing things. There has been enough research into user interfaces that a interface based on these principles, like GNOME, can be objectively very efficient.
As for dumbing down, its a red-herring. There isn't really much you cannot do in GNOME (aside from customization --- which isn't an end in itself) that you can do in KDE. GNOME's features aren't that sparse, they're just not in your face at every turn. GNOME depends more heavily on the user taking advantage of the full range of his/her interaction capabilities. So in the GTK+ file dialog, you have to hit CTRL-L to get the path bar, but in the common case of when you're already in the directory you want and the file is staring right at you, you don't have to deal with the mental baggage of having to look at the path bar.
The whole idea of "dumb" interfaces is idiotic. GNOME isn't a "dumb" interface, it's an interfaced that's actually designed according to UI principles. This does not mean designing to dumb users or new users, but designing to accomodate the inherent limitations of the human mind. The same things that make the UI discoverable for new users (minimal clutter, proper layout, etc), also make it more efficient for experienced users. Some of the things KDE apps do (like Konqueror's enormous right-click menus), are just objectively wrong. Human have the ability to memorize lists of 5-7 items. A context menu with a dozen items means the person has to read it instead of just invoking muscle memory. That's not preference, that's fact. The spacing stuff is unforgiveable too. It goes against everything people are taught about page layout. Lots of other things as asthetically egregious. That's not a "smart" interface, its a bad one.
You can't fix KDE's UI shortcomings without substantially redesigning the UI, and actually imposing some order on the developers (trust me, I've tried). KDE's UI suffers from the following major problems:
1) Poor use of whitespace. Notice how TeX formats documents. There is tons of whitespace in a TeX formatted document. Why? Because it looks good and more importantly makes things easier to read. KDE people think whitespace is wasted pixels that could be better put to use with another widget in them.
2) Cluttered layouts. There are too many widgets, toolbar buttons, context menu items, etc, in KDE apps, and there is nothing that can be done about it without fundementally redesigning the UIs.
3) The KDE project doesn't enforce rules. KDE is a project where developers come first. GNOME is a project where the software comes first. KDE's stance is admirable, but inappropriate for designing software for mass consumption. In the GNOME world, if an app isn't HIG-compliant, it doesn't get into core GNOME. In the GNOME world, if a feature isn't consistent with the rest of the desktop, it is removed, even if that is an unpopular decision among developers. A user interface is a design, and designs need to be consistent, in everything from spacing, to layout, to color. Just as an architect doesn't designs a building according to a single vision, so to must a programmer design a UI according to a single vision. There is nobody in the KDE project able to enforce a vision.
Interestingly enough, this extends to technical design as well. GNOME hopped on the GStreamer bandwagon awhile ago. KDE put off the decision, and ultimately, since no consensus was reachable, they decided to create yet another audio wrapper framework just so there wouldn't have to be a hard technical decision about what sound system to use. If Trolltech hadn't made the decision of what vector graphics toolkit to use for them, by building Arthur into Qt, they likely would have argued about Cairo versus Anti-Grain versus Amathyst, and ultimately created a wrapper over that too.
LOL. I'm a KDE user who converted to GNOME for exactly the opposite reason. I was originally draw to KDE's technical superiority, but then realized that I had to fight it every step of the way to clean up the interface. I got KDE looking quite good, with only a few toolbar buttons and minimal context menus, and then realized that every time I upgraded, I had to do it all over again. I looked at GNOME, and saw that even though it was slower and technically inferior, GNOME HIG apps looked like I'd been configuring KDE to look all the time. They actually paid attention to font spacing, making simple context menus, color and icon consistency, not overcrowding the toolbar, etc. KDE folks treat whitespace like its a bad thing, while GNOME programmers lay out whitespace liberally to seperate logically seperate interface components and make things more pleasing to the eye. Ultimately, GNOME does UI stuff according to scientific principles of design, while KDE does things according to some preconcieved idea of what's efficient.
There is also the flip-side to it. Windows compatibility lets a lot more people use OS X that could not otherwise do so. For those people that need to run that one Windows app once in awhile, dual-boot capability (or better, virtualization) would mean the difference between running OS X 99% of the time and running OS X 0% of the time.
Ultimately, people buy Macs to run OS X. If people wanted to run Windows, they wouldn't be buying Macs...
Where do you get the idea that most users will run Windows over OS X on their hardware? All those years when Apple was selling a million PowerPC Macs a year, people were buying them despite the fact that they could get a Windows-running PC for substantially less money. Your argument is tantamount to the assertion that Apple computers sell because of the superiority of the hardware, not OS X. That's a stupid idea, because for a long time, Apple hardware was quite inferior and overpriced in many respects.
I know I bought a PowerMac G5 expressly for the purpose of running OS X, even though it was at the same time more expensive and slower than the PC I already had. For the stuff I do (programming, engineering, basic office tasks), the Mac is a far more productive platform than Windows. Its more secure, requires almost zero maintainence, has a high degree of *NIX integration, and runs all the software I want (Matlab, Mathematica, TeX, gcc, etc).
You're not comparing Java in that case, then, you're comparing Win32 versus Swing, or whatever. Yo might as well point to GTK+ apps being slower than Win32 apps and come to the conclusion that C is slower than C...
Actually, it confirmed nothing except that fewer neutrinos were detected. It is utterly foolish to think that particle physics is enough understood that accurate guesses can be made.
Actually, particle physics is very well understood.
Then why are AMD processors consistantly faster than their Intel counterparts when their clock speed is considerably lower?
Because AMD chips can sustain more IPC. I never said Hz was a perfect measurement of performance. However, if confronted with a 8 GHz P4 and a 2 GHz AMD chip, you can be pretty sure the P4 will be faster. IPC's are similar enough in range (within a factor of 2 within similar processor classes), that if a processor is clocked 4x higher you can be pretty sure it'll be faster, regardless of IPC. Moreover, if we're talking about processors with the same architecture, you can assume performance scales linearly with clockspeed within a fairly wide range. That's exactly what were talking about here --- the XBox 360 and PS3 chips have a 4x clockspeed advantage, while the Revolution chip is another PowerPC 750 derivative. The PowerPC 750 is not an Athlon-style design. It's got extremely limited out-of-order execution, and architecturally, its prime benefit over the Cell and Xenon are lower instruction and cache latencies, as well as a shorter pipeline. It'll be lucky to sustain 50% more IPC than the PPE, much less the 300% more it needs to be competitive.
The fact you still think Hz matters shows how much you truely know about microchip architecture.
Of course Hz matters! Clockspeed is the first-order differentiator of performance. You clock a design 50% higher, it'll run code 50% faster! Of all the single parameters of a CPU, clockspeed is the one that gives you the best indicator of performance. Its not a fine-enough tool to distinguish the actual performance of a 2 GHz processor from a 3 GHz processor, but it'll certainly be good enough for 700 MHz versus 3.2 GHz. You see, within a processor class, IPC doesn't vary over that wide a range. A state of the art Athlon 64 has an IPC less than 80% higher than an old IBM 604e. When you're talking about clock-speed deltas as high as we are here, the IPC delta won't be high enough to make that big of a difference.
Programs usualy contain branching statements and dependant variables, thus you wouldnt get more than 9-10 operations before you encounter a conditional statement or a variable dependant on a prior operation.
9-10??? The branch density on common integer code is 1 every 4-5 instructions. Dependent integer instructions happen so often that even a 1-cycle delay for dependent integer operations hurts your IPC significantly. You're also forgetting one key factor that limits IPC --- cache latencies. Cache latencies can cause the processor to stall waiting for memory operands. Very deep out-of-order execution can paper over L1 and L2 cache latencies, but the Gecko isn't a deeply OOO processor.
That aside, the example was showing in an ideal world that Hz alone means nothing when you comparing processors performing identical tasks.
We're not talking about the ideal world, however, we're talking about the real-world. In the real-world, you're lucky to get 2-3 IPC, much less 30. In the real world, IPC considerations aren't enough to significantly alter a comparison with a 4x clockspeed gap. On top of all that, you're talking as if the 750 CPU is some sort of IPC monster. It's not. It's one step up from an in-order chip. It has two integer units, one FPU, and one LSU. It has reservation stations that are 1 or instructions deep, and has a OOO window of about half a dozen instructions. Even the PIII in the original XBox is a far more sophisticated chip. It has similar execution resources, though it has more load/store hardware, but a 20-entry scheduler and a 40-entry OOO window. These resources allow the chip to extract a lot more IPC out of the same amount of execution resources than the 750 can. Both chips are a far cry from a modern IPC monster like the Conroe or Athlon 64. Conroe has about twice the number of execution units as the PIII, as well as a 32-entry scheduler and a massive 96-entry OOO window.
So ultimately, you're comparisons of Athlon 64 versus P4 are really not relevan
1) The "bloat" of mainstream OSs really has absolutely nothing to do with anything in this discussion. The Gecko core is still a G3 at heart, in all the ways that matter. It has some tricks like 2-way SIMD in the FPU, but it performs just like a G3 at the same clockspeed.
2) A 30-way 100 MHz processor would not be much faster than a 4-way 100 MHz processor, much less a 1-way 3 GHz processor. The ILP of most code is limited to 2-3 way most of the time, with bursts of 4-5 once in a while.
3) Chip companies have Hz wars because Hz is a first-order impact on performance, and increasing IPC is very difficult. With modern processors, doubling the processor width is likely to net 10-20% improvement in performance. Worse, since many things within the processor scale quadratically with the number of execution units, doubling the processor width effectively quadruples the size of many timing-critical structures. That's why mainstream processors have stuck to 3-4 way designs for the last decade.
4) Hz is a first-order measurement of processor performance. Within similar classes of chip (in-order), it's a good estimator for performance. It's far better, anyway, than any other single property of the processor.
Yes it is, but the 750 is the G3, and the same basic core that was in the Gamecube. It was an impressive processor in 1996, when 300 MHz G3s were competing with 200 MHz Pentiums, but this is 2006.
Really, so the graphically superior FIFA games are better games than than their rival Pro Evolution Soccer?
The difference in graphical quality isn't very big in this particular case. However, with the Revolution, the graphics quality is going to be a generation apart. While you and your friends may play old, graphically inferior sports games, most people do not. I don't know a single person who still plays sports games for the N64, though I know lots of people who still play N64 platformers.
Check out the list of the best RPGs, or just the best games, of all time: graphics are not the edge for any of them, and in many cases they were comparatively primitive graphically even for the time. Ultima III, Ocarina of Time, the Civ series... Not a list about graphical horsepower. All "epic."
Except Ultima III, none of the games you mention are console RPGs. Console RPGs are things like Final Fantasy, the DragonQuest series, Chrono Trigger, etc. Most of the good RPGs I've played were quite graphically competent for their time period. Chrono Trigger looks dated today, but back when it came out, it looked very good. The Final Fantasy games have always been fairly close to the edge in terms of graphics. An important thing to remember is that graphics doesn't just determine how users will perceive the game, but it will determine what games get made. the PS3 is likely to remain the #1 system for RPGs, simply because it allows developers the most freedom to create a graphically rich and engrossing RPG. The Revolution's hardware specs may very well cause a repeat of the N64-disaster. Top RPG makers stayed of the N64, because its cart-format was much more limiting for the resulting game than the CD format of the PSX.
That's an idiotic reference. The 440-based machines perform well because there are tens of thousands of them hooked up to interconnects that cost more than your house. Each chip itself is a fairly slow, low-power design. The Revolution includes only a single chip, and it appears that even this isn't a newer 440, but a faster-clocked Gecko, which is a 750-based chip.
No, but a 2 GHz Athlon XP is just a 1.5 GHz Athlon XP with a 2 GHz clockspeed. Read the article more carefully --- the Revolution chips are not new designs. They're warmed-over versions of the Gamecube chips.
The article says that the Revolution hardware is just updated versions of the Gamecube hardware. It looks like Nintendo did little or no redesign of the components, other than perhaps a die-shrink that allowed for higher-clockspeeds and lower cost. Consider, for example, the 3MB of memory integrated on the Flipper chip. It would've been quite easy to expand this to something larger if Nintendo was already overhauling the GPU, but the fact that its the exact same suggests that Flipper is more or less unchanged. Also consider the split memory architecture. You think that if Nintendo was just going to put 88MB of 1T-SRAM in the machine, they wouldn't bother splitting it up like that (the original split in the GC was because the secondary memory was of a different, cheaper, type). Since they didn't, that indicates they're keeping the same memory architecture as the GC, suggesting that they haven't updated the supporting chipset much if at all.
All that's been released is the clockspeed of the processors.
And the fact that the architectures are identical to the Gamecube ones. That means the CPU is basically a 730MHz Gecko and the GPU is a 240 MHz Flipper. The per clock performance of the Gecko chip (which is basically a G3 with integrated cache and the ability to use its 64-bit FPU as a 2x32-bit SIMD engine) is probably quite a bit better than the Xenon, but enough to make up for the enormous clockspeed difference.
The G3 is a very ancient chip. It has almost no OOO capability. Per-clock, its probably going to be faster than Cell, but considering that the per-clock of the PIII-based core in the XBox is in line with the G4, it won't match up even to the older console in CPU performance. As for graphics chips --- clockspeed times the number of pipelines is an excellent predictor of GPU performance. Only in a relatively small number of cases (eg: the Geforce FX debacle for NVIDIA), has pure fill-rate proved to be a poor predictor of overall performance in the case of conventional GPUs. The integrated memory helps the Flipper chip quite a bit, but given that it h as about the same clock-rate and the same number of pipelines as the XBox GPU, I wouldn't expect much more than that level of performance out of it. Overall, expect the Revolution to perform somewhat like a slightly improved XBox. Between the 1T-SRAM and the familiarity of developers with the GC architecture, Revolution developers should be able to wring substantially more out of the Revolution than they did out of the XBox, but I'd be surprised if the improvement was more than 50%.
You're wrong. Out of order execution helps when you have memory and cache latencies. Basically, on any modern processor, where it takes multiple cycles to access even the L1 data cache.
There are lots of classes of games for which graphics are important. Take for example sports games which are very popular in the US. Graphics are critical for such games to reproduce the realism of a real sports event. Since the actual game rules are fixed by the sport, there isn't a whole lot of room to innovate in the gameplay department, so going in the realism direction is the best option.
Also consider the genre of first-person shooters (which are also popular in the US). Graphics are important not just for creating atmosphere, but HD graphics are going to be great for multiplayer maps (you can see farther with more detail). CPU power is going to be critical to feed the advanced physics and AI engines that modern games are sporting. Take a game like F.E.A.R, whose great animation, physics, and AI really add to the experience, and shoe-horn it into the revolution, and you lose a lot of the specialness of the game.
Or consider RPGs. Console RPGs depend on a great degree on the ability to tell a story. Good graphics and animation are critical in conveying the epic feel of an interactive story. I mean, what would LOTR be without the sweeping views of the New Zealand countryside, or the huge, detailed shots of giant armies?
It seems very clear to me that the Revolution is destined to be another Gamecube: basically, a console only good for playing Nintendo's first-party titles. Sure, most of those are very good games, but how much is really in that library for a sports, RPG, or FPS fanatic? Because between the tastes of Japan and the United States, these are the genres that are really important to gamers. Of course, you could argue that Nintendo is aiming at a completely different market with the Revolution (eg: "The Sims" market), which could very well be true, but in that case, Nintendo isn't really competing in the same sphere as Microsoft and Sony.
The docs at developer.apple.com arent exactly accurate. Looking at Darwin as "FreeBSD 5.0" is very misleading. It makes far more sense to look at the lineage of the various subsystems within the OS. That lineage is as follows:
1) Kernel core: Mach 3.0, which is itself derived from an old version of BSD. This handles a lot of the grunt work of the kernel, including scheduling, memory protection, virtual memory, IPC, device drivers, low-level I/O, power management, and interrupts. This component is completel different from the corresponding components of FreeBSD, and Apple cannot easily re-use FreeBSD innovations in these areas.
2) BSD core: The core of the BSD subsystem is 4.4BSD-Lite2 + NeXT/Apple extensions. That means a lot of the basic primitives in the BSD component, such as locking, are different from those in FreeBSD.
3) Security model: From 4.4BSD-Lite2.
4) Virtual filesystem + file I/O: From FreeBSD.
5) Network stack: from FreeBSD
6) System call API: from FreeBSD, but modified to call into Mach.
7) Crypto stack: from OpenBSD
8) Userspace: from FreeBSD
As you can see, the main things handled by the FreeBSD code are file and network I/O, and the userspace libraries and utilities. However, Apple still doesn't source a lot of code from FreeBSD for these components, because the locking model used in XNU's BSD core and the one used in FreeBSD are completely different. So in general, the relationship between Darwin and FreeBSD really isn't that tight, certainly not as tight as, say, the one between NetBSD and FreeBSD, and the code flow from one to the other is fairly minimal. If you look at where the heavy work in OS X has been going on over the past few years (driver improvements, HFS+ improvements, threading improvements), you'll see that most of that work has been in non-FreeBSD components. In practice, its really not accurate to say that Darwin's model is really different from Microsoft's "shared-source" one, asiding from the licensing issues. For all intents and purposes, Apple does 99% of Darwin development, while Microsoft does 100% of Windows development.
A Mac system that runs comparable to my desktop system (which is only a 2.2 AMD with 2 gigs of RAM) that I spent about 1100 dollars building would cost in the neighborhood of 3000 dollars.
That's not really true any longer. It's true that when I bought my PowerMac, I got a $2700 machine that was a bit less than comparable to my $1700 AMD machine, but the new Intel Macs are a different story. For what I do (compiling), the 2.0 GHz Core Duo in the 20" iMac is directly comparable to a 2.2 GHz Athlon X2. For $1700, the same as I paid for my AMD machine, I get a machine with less RAM (512MB versus 2GB), but with a good 20" LCD, video camera, wireless ethernet, bluetooth, and even a remote.
Now, its important to compare apples to apples here. Most home-built PCs are crap from an ergonomic point of view. They're loud and built with flimsy cases. The iMac, on the other hand, is very quiet and very solid. Since I can't stand computer noise interefering with my thought process while programming, I built my AMD machine the same way, which accounts for its relatively high price. If ergonomics isn't a feature you want in your machine, obviously you can build it for less, but then you're not really comparing the same thing anymore.
Now, it's safe to say that Macs will always carry a price premium. The premium may or may not be worth it to you, depending on how much you like OS X. Since OS X is a software developer's paradise, I consider it well worth the $700-$1000 extra I paid for my PowerMac. However, its also safe to say that with the Intel transition, the premium is going to become less of a problem. What made the premium particularly bad for Macs of the past was the fact that even high-end PowerPC processors were comparable more to mid-range x86 processors. So you'd take a high-end (and priced that way) machine like the top PowerMacs, then have to compare them to mid-range (and priced that way) Intel machines.
With the Intel transition, that variation is eliminated, and your "OS X tax" is basically Apple's larger margin on their hardware. Considering that Dell's margin of ~10% puts the actual price of a $2000 machine at $1800, and that Apple's marging of ~25% puts the price of the same machine at ~$2250, that makes for a premium of only a couple of hundred dollars on most of the price range. That's quite a reasonable premium for a high-end brand and the advantages of OS X.
A.) I can let a 6 year old install software on a Windows system... But I have to train someone who has 20 years of computer experience on how to find their files on a Mac.
Um, what? Installing software in OS X is a matter of dragging a file to a specific folder. Are you telling me a wizard is more complex than that? And findng files is about as complicated as clicking the Finder icon, and boom, there is your home folder! Hell, as of Vista, the user-specific file hierarchy in Vista will be the same as in OS X (root directory) -> Users -> (home directory).
You're wrong. OS X is based on NeXTStep. Now, NeXT Step is itself a BSD derivative --- it used a 4.3 BSD system server on top of a Mach 2.x microkernel, which was itself a derivative of an earlier version of BSD. During the development of OpenStep (NeXTStep 4.x), the 4.3 BSD code was repalaced with 4.4 BSD-Lite2 code (along with lots of NeXT-specific additions), and when Apple acquired the OS to turn it into OS X, the microkernel was upgraded to Mach 3.x, the system server was fused into the kernel, and some substantial FreeBSD components (networking, filesystems), were integrated with the 4.4 BSD code.
So while there is substantial FreeBSD code in Darwin, Darwin is not FreeBSD. Apple still does almost all the development of Darwin, and has evolved the kernel is a somewhat different direction than FreeBSD. Darwin's new fine-grained locking model (which appeared in Tiger) is substantially simpler than FreeBSD 5.x's locking model, it doesn't use the new FreeBSD ULE scheduler, it doesn't use GEOM, it's driver and power management API, contained in the IOKit, is completely different, etc. Apple can still use FreeBSD code here and there, such as the IPV6 stack, updated networking components, UFS improvements, etc, but the core kernel is different enough that the code sharing doesn't extend much beyond that.
Translucency and alpha blending are the same thing. All the effects I mentioned are just uses of translucency to varying degrees. The curved window borders are translucent (with zero opacity --- just an extreme case of translucency), while the menus, etc, are more opaque, but still translucent.
Your original post implied that you thought the definition of translucency had something to do with blurring, while the conventional usage of the term in reference to computer UIs refers to very specific capability --- alpha-blending of window buffers. This term is fairly precise, indeed, even mathematically so, in that it implies a particular blending equation on top of everything else.
Anyway, my point was that if Vista can do it, OS X can do it. Quarz Compositor has access to all the window buffers on the display as a texture. From there, it can leverage CoreImage to use the pixel shaders to perform a blur effect, the composite the result onto the framebuffer. Now, Apple doesn't use blurring in the UI, but that's independent of whether OS X can perform the effect.
Slashdot Mirror
At a technical level, the difference between OOO and IO is thus: an OOO Processor can issue, via a structure called a reservation station, instructions in an order other than what is in the code stream. So say the CPU decodes instructions A, B, C, and D, in that order. These instructions go into a reservation station. Instructions in this structure sit there until all its source operands are available. That means if A, B, C, and D enter the RS, but B and C's operands are available before A and D's, B and C will execute before A and D.
The key use of OOO is two fold. First, it reduces the compiler's burder. Say the CPU is designed so the latency between two FPU additions is 4 clock cycles. With an in-order processor, the compiler would have to schedule code so there are 4 independent operations between each pair of dependent ones. If a dependent operation shows up in the code stream before the instruction it depends on has completed, the processor will just wait there while the instruction finishes, even if there are instructions in the queue behind the dependent one that could be executing in the mean time. In an OOO processor, if independent instructions arrive while a particular instruction is waiting for some operands, they'll be executed ahead of the waiting instruction.
The other use of OOO is to cover the latencies to caches and memory. Typically, L1 caches have a latency of 3 cycles, while L2 caches have latencies of 10-30 cycles, and memory has latencies of upwards of 150 cycles. If an instruction arrives that requires results from memory, it could be waiting anywhere from 3-150 cycles for that data to arrive, depending on what is cached. In an in-order processor, this could cause the CPU to stall for a very long time doing nothing, even when there are instructions behind the waiting one that could be executing in the meantime.
Oh really? Took me a minute (at most) todo this on konqueror.
.kde directory. Then I realized that GNOME looked exactly the way I wanted, out of the box. Moreover, GNOME's widget layouts are right, and its color coordination and useage of spacing is far superior to KDE's. These things may seem like small details, but make the UI much less tiring to use over a long period of time.
I used to do that too (indeed, my layout looked almost exactly like that). Then I realized I had to do it over for every app. Or every time I tried a new distribution. Or whenever I had to wipe my
I really like the customisability of KDE applications, one of the reason why I use KDE in particular. I like having access to advanced tools if I need it. I'd rather not have a dumbed down UI.
The thing about customizability is this: its usually a bad thing. The way people want to work is usually not the way they should be working. This is a fact in many facets of life --- that's precisely why every industry you'll encounter has "best practices" to teach you how you should be doing things. There has been enough research into user interfaces that a interface based on these principles, like GNOME, can be objectively very efficient.
As for dumbing down, its a red-herring. There isn't really much you cannot do in GNOME (aside from customization --- which isn't an end in itself) that you can do in KDE. GNOME's features aren't that sparse, they're just not in your face at every turn. GNOME depends more heavily on the user taking advantage of the full range of his/her interaction capabilities. So in the GTK+ file dialog, you have to hit CTRL-L to get the path bar, but in the common case of when you're already in the directory you want and the file is staring right at you, you don't have to deal with the mental baggage of having to look at the path bar.
The whole idea of "dumb" interfaces is idiotic. GNOME isn't a "dumb" interface, it's an interfaced that's actually designed according to UI principles. This does not mean designing to dumb users or new users, but designing to accomodate the inherent limitations of the human mind. The same things that make the UI discoverable for new users (minimal clutter, proper layout, etc), also make it more efficient for experienced users. Some of the things KDE apps do (like Konqueror's enormous right-click menus), are just objectively wrong. Human have the ability to memorize lists of 5-7 items. A context menu with a dozen items means the person has to read it instead of just invoking muscle memory. That's not preference, that's fact. The spacing stuff is unforgiveable too. It goes against everything people are taught about page layout. Lots of other things as asthetically egregious. That's not a "smart" interface, its a bad one.
You can't fix KDE's UI shortcomings without substantially redesigning the UI, and actually imposing some order on the developers (trust me, I've tried). KDE's UI suffers from the following major problems:
1) Poor use of whitespace. Notice how TeX formats documents. There is tons of whitespace in a TeX formatted document. Why? Because it looks good and more importantly makes things easier to read. KDE people think whitespace is wasted pixels that could be better put to use with another widget in them.
2) Cluttered layouts. There are too many widgets, toolbar buttons, context menu items, etc, in KDE apps, and there is nothing that can be done about it without fundementally redesigning the UIs.
3) The KDE project doesn't enforce rules. KDE is a project where developers come first. GNOME is a project where the software comes first. KDE's stance is admirable, but inappropriate for designing software for mass consumption. In the GNOME world, if an app isn't HIG-compliant, it doesn't get into core GNOME. In the GNOME world, if a feature isn't consistent with the rest of the desktop, it is removed, even if that is an unpopular decision among developers. A user interface is a design, and designs need to be consistent, in everything from spacing, to layout, to color. Just as an architect doesn't designs a building according to a single vision, so to must a programmer design a UI according to a single vision. There is nobody in the KDE project able to enforce a vision.
Interestingly enough, this extends to technical design as well. GNOME hopped on the GStreamer bandwagon awhile ago. KDE put off the decision, and ultimately, since no consensus was reachable, they decided to create yet another audio wrapper framework just so there wouldn't have to be a hard technical decision about what sound system to use. If Trolltech hadn't made the decision of what vector graphics toolkit to use for them, by building Arthur into Qt, they likely would have argued about Cairo versus Anti-Grain versus Amathyst, and ultimately created a wrapper over that too.
LOL. I'm a KDE user who converted to GNOME for exactly the opposite reason. I was originally draw to KDE's technical superiority, but then realized that I had to fight it every step of the way to clean up the interface. I got KDE looking quite good, with only a few toolbar buttons and minimal context menus, and then realized that every time I upgraded, I had to do it all over again. I looked at GNOME, and saw that even though it was slower and technically inferior, GNOME HIG apps looked like I'd been configuring KDE to look all the time. They actually paid attention to font spacing, making simple context menus, color and icon consistency, not overcrowding the toolbar, etc. KDE folks treat whitespace like its a bad thing, while GNOME programmers lay out whitespace liberally to seperate logically seperate interface components and make things more pleasing to the eye. Ultimately, GNOME does UI stuff according to scientific principles of design, while KDE does things according to some preconcieved idea of what's efficient.
There is also the flip-side to it. Windows compatibility lets a lot more people use OS X that could not otherwise do so. For those people that need to run that one Windows app once in awhile, dual-boot capability (or better, virtualization) would mean the difference between running OS X 99% of the time and running OS X 0% of the time.
Ultimately, people buy Macs to run OS X. If people wanted to run Windows, they wouldn't be buying Macs...
Where do you get the idea that most users will run Windows over OS X on their hardware? All those years when Apple was selling a million PowerPC Macs a year, people were buying them despite the fact that they could get a Windows-running PC for substantially less money. Your argument is tantamount to the assertion that Apple computers sell because of the superiority of the hardware, not OS X. That's a stupid idea, because for a long time, Apple hardware was quite inferior and overpriced in many respects.
I know I bought a PowerMac G5 expressly for the purpose of running OS X, even though it was at the same time more expensive and slower than the PC I already had. For the stuff I do (programming, engineering, basic office tasks), the Mac is a far more productive platform than Windows. Its more secure, requires almost zero maintainence, has a high degree of *NIX integration, and runs all the software I want (Matlab, Mathematica, TeX, gcc, etc).
You're not comparing Java in that case, then, you're comparing Win32 versus Swing, or whatever. Yo might as well point to GTK+ apps being slower than Win32 apps and come to the conclusion that C is slower than C...
Actually, it confirmed nothing except that fewer neutrinos were detected. It is utterly foolish to think that particle physics is enough understood that accurate guesses can be made.
Actually, particle physics is very well understood.
Then why are AMD processors consistantly faster than their Intel counterparts when their clock speed is considerably lower?
Because AMD chips can sustain more IPC. I never said Hz was a perfect measurement of performance. However, if confronted with a 8 GHz P4 and a 2 GHz AMD chip, you can be pretty sure the P4 will be faster. IPC's are similar enough in range (within a factor of 2 within similar processor classes), that if a processor is clocked 4x higher you can be pretty sure it'll be faster, regardless of IPC. Moreover, if we're talking about processors with the same architecture, you can assume performance scales linearly with clockspeed within a fairly wide range. That's exactly what were talking about here --- the XBox 360 and PS3 chips have a 4x clockspeed advantage, while the Revolution chip is another PowerPC 750 derivative. The PowerPC 750 is not an Athlon-style design. It's got extremely limited out-of-order execution, and architecturally, its prime benefit over the Cell and Xenon are lower instruction and cache latencies, as well as a shorter pipeline. It'll be lucky to sustain 50% more IPC than the PPE, much less the 300% more it needs to be competitive.
The fact you still think Hz matters shows how much you truely know about microchip architecture.
Of course Hz matters! Clockspeed is the first-order differentiator of performance. You clock a design 50% higher, it'll run code 50% faster! Of all the single parameters of a CPU, clockspeed is the one that gives you the best indicator of performance. Its not a fine-enough tool to distinguish the actual performance of a 2 GHz processor from a 3 GHz processor, but it'll certainly be good enough for 700 MHz versus 3.2 GHz. You see, within a processor class, IPC doesn't vary over that wide a range. A state of the art Athlon 64 has an IPC less than 80% higher than an old IBM 604e. When you're talking about clock-speed deltas as high as we are here, the IPC delta won't be high enough to make that big of a difference.
Programs usualy contain branching statements and dependant variables, thus you wouldnt get more than 9-10 operations before you encounter a conditional statement or a variable dependant on a prior operation.
9-10??? The branch density on common integer code is 1 every 4-5 instructions. Dependent integer instructions happen so often that even a 1-cycle delay for dependent integer operations hurts your IPC significantly. You're also forgetting one key factor that limits IPC --- cache latencies. Cache latencies can cause the processor to stall waiting for memory operands. Very deep out-of-order execution can paper over L1 and L2 cache latencies, but the Gecko isn't a deeply OOO processor.
That aside, the example was showing in an ideal world that Hz alone means nothing when you comparing processors performing identical tasks.
We're not talking about the ideal world, however, we're talking about the real-world. In the real-world, you're lucky to get 2-3 IPC, much less 30. In the real world, IPC considerations aren't enough to significantly alter a comparison with a 4x clockspeed gap. On top of all that, you're talking as if the 750 CPU is some sort of IPC monster. It's not. It's one step up from an in-order chip. It has two integer units, one FPU, and one LSU. It has reservation stations that are 1 or instructions deep, and has a OOO window of about half a dozen instructions. Even the PIII in the original XBox is a far more sophisticated chip. It has similar execution resources, though it has more load/store hardware, but a 20-entry scheduler and a 40-entry OOO window. These resources allow the chip to extract a lot more IPC out of the same amount of execution resources than the 750 can. Both chips are a far cry from a modern IPC monster like the Conroe or Athlon 64. Conroe has about twice the number of execution units as the PIII, as well as a 32-entry scheduler and a massive 96-entry OOO window.
So ultimately, you're comparisons of Athlon 64 versus P4 are really not relevan
1) The "bloat" of mainstream OSs really has absolutely nothing to do with anything in this discussion. The Gecko core is still a G3 at heart, in all the ways that matter. It has some tricks like 2-way SIMD in the FPU, but it performs just like a G3 at the same clockspeed.
2) A 30-way 100 MHz processor would not be much faster than a 4-way 100 MHz processor, much less a 1-way 3 GHz processor. The ILP of most code is limited to 2-3 way most of the time, with bursts of 4-5 once in a while.
3) Chip companies have Hz wars because Hz is a first-order impact on performance, and increasing IPC is very difficult. With modern processors, doubling the processor width is likely to net 10-20% improvement in performance. Worse, since many things within the processor scale quadratically with the number of execution units, doubling the processor width effectively quadruples the size of many timing-critical structures. That's why mainstream processors have stuck to 3-4 way designs for the last decade.
4) Hz is a first-order measurement of processor performance. Within similar classes of chip (in-order), it's a good estimator for performance. It's far better, anyway, than any other single property of the processor.
Yes it is, but the 750 is the G3, and the same basic core that was in the Gamecube. It was an impressive processor in 1996, when 300 MHz G3s were competing with 200 MHz Pentiums, but this is 2006.
Really, so the graphically superior FIFA games are better games than than their rival Pro Evolution Soccer?
The difference in graphical quality isn't very big in this particular case. However, with the Revolution, the graphics quality is going to be a generation apart. While you and your friends may play old, graphically inferior sports games, most people do not. I don't know a single person who still plays sports games for the N64, though I know lots of people who still play N64 platformers.
Check out the list of the best RPGs, or just the best games, of all time: graphics are not the edge for any of them, and in many cases they were comparatively primitive graphically even for the time. Ultima III, Ocarina of Time, the Civ series... Not a list about graphical horsepower. All "epic."
Except Ultima III, none of the games you mention are console RPGs. Console RPGs are things like Final Fantasy, the DragonQuest series, Chrono Trigger, etc. Most of the good RPGs I've played were quite graphically competent for their time period. Chrono Trigger looks dated today, but back when it came out, it looked very good. The Final Fantasy games have always been fairly close to the edge in terms of graphics. An important thing to remember is that graphics doesn't just determine how users will perceive the game, but it will determine what games get made. the PS3 is likely to remain the #1 system for RPGs, simply because it allows developers the most freedom to create a graphically rich and engrossing RPG. The Revolution's hardware specs may very well cause a repeat of the N64-disaster. Top RPG makers stayed of the N64, because its cart-format was much more limiting for the resulting game than the CD format of the PSX.
That's an idiotic reference. The 440-based machines perform well because there are tens of thousands of them hooked up to interconnects that cost more than your house. Each chip itself is a fairly slow, low-power design. The Revolution includes only a single chip, and it appears that even this isn't a newer 440, but a faster-clocked Gecko, which is a 750-based chip.
No, but a 2 GHz Athlon XP is just a 1.5 GHz Athlon XP with a 2 GHz clockspeed. Read the article more carefully --- the Revolution chips are not new designs. They're warmed-over versions of the Gamecube chips.
The article says that the Revolution hardware is just updated versions of the Gamecube hardware. It looks like Nintendo did little or no redesign of the components, other than perhaps a die-shrink that allowed for higher-clockspeeds and lower cost. Consider, for example, the 3MB of memory integrated on the Flipper chip. It would've been quite easy to expand this to something larger if Nintendo was already overhauling the GPU, but the fact that its the exact same suggests that Flipper is more or less unchanged. Also consider the split memory architecture. You think that if Nintendo was just going to put 88MB of 1T-SRAM in the machine, they wouldn't bother splitting it up like that (the original split in the GC was because the secondary memory was of a different, cheaper, type). Since they didn't, that indicates they're keeping the same memory architecture as the GC, suggesting that they haven't updated the supporting chipset much if at all.
All that's been released is the clockspeed of the processors.
And the fact that the architectures are identical to the Gamecube ones. That means the CPU is basically a 730MHz Gecko and the GPU is a 240 MHz Flipper. The per clock performance of the Gecko chip (which is basically a G3 with integrated cache and the ability to use its 64-bit FPU as a 2x32-bit SIMD engine) is probably quite a bit better than the Xenon, but enough to make up for the enormous clockspeed difference.
The G3 is a very ancient chip. It has almost no OOO capability. Per-clock, its probably going to be faster than Cell, but considering that the per-clock of the PIII-based core in the XBox is in line with the G4, it won't match up even to the older console in CPU performance. As for graphics chips --- clockspeed times the number of pipelines is an excellent predictor of GPU performance. Only in a relatively small number of cases (eg: the Geforce FX debacle for NVIDIA), has pure fill-rate proved to be a poor predictor of overall performance in the case of conventional GPUs. The integrated memory helps the Flipper chip quite a bit, but given that it h as about the same clock-rate and the same number of pipelines as the XBox GPU, I wouldn't expect much more than that level of performance out of it. Overall, expect the Revolution to perform somewhat like a slightly improved XBox. Between the 1T-SRAM and the familiarity of developers with the GC architecture, Revolution developers should be able to wring substantially more out of the Revolution than they did out of the XBox, but I'd be surprised if the improvement was more than 50%.
You're wrong. Out of order execution helps when you have memory and cache latencies. Basically, on any modern processor, where it takes multiple cycles to access even the L1 data cache.
There are lots of classes of games for which graphics are important. Take for example sports games which are very popular in the US. Graphics are critical for such games to reproduce the realism of a real sports event. Since the actual game rules are fixed by the sport, there isn't a whole lot of room to innovate in the gameplay department, so going in the realism direction is the best option.
Also consider the genre of first-person shooters (which are also popular in the US). Graphics are important not just for creating atmosphere, but HD graphics are going to be great for multiplayer maps (you can see farther with more detail). CPU power is going to be critical to feed the advanced physics and AI engines that modern games are sporting. Take a game like F.E.A.R, whose great animation, physics, and AI really add to the experience, and shoe-horn it into the revolution, and you lose a lot of the specialness of the game.
Or consider RPGs. Console RPGs depend on a great degree on the ability to tell a story. Good graphics and animation are critical in conveying the epic feel of an interactive story. I mean, what would LOTR be without the sweeping views of the New Zealand countryside, or the huge, detailed shots of giant armies?
It seems very clear to me that the Revolution is destined to be another Gamecube: basically, a console only good for playing Nintendo's first-party titles. Sure, most of those are very good games, but how much is really in that library for a sports, RPG, or FPS fanatic? Because between the tastes of Japan and the United States, these are the genres that are really important to gamers. Of course, you could argue that Nintendo is aiming at a completely different market with the Revolution (eg: "The Sims" market), which could very well be true, but in that case, Nintendo isn't really competing in the same sphere as Microsoft and Sony.
The docs at developer.apple.com arent exactly accurate. Looking at Darwin as "FreeBSD 5.0" is very misleading. It makes far more sense to look at the lineage of the various subsystems within the OS. That lineage is as follows:
1) Kernel core: Mach 3.0, which is itself derived from an old version of BSD. This handles a lot of the grunt work of the kernel, including scheduling, memory protection, virtual memory, IPC, device drivers, low-level I/O, power management, and interrupts. This component is completel different from the corresponding components of FreeBSD, and Apple cannot easily re-use FreeBSD innovations in these areas.
2) BSD core: The core of the BSD subsystem is 4.4BSD-Lite2 + NeXT/Apple extensions. That means a lot of the basic primitives in the BSD component, such as locking, are different from those in FreeBSD.
3) Security model: From 4.4BSD-Lite2.
4) Virtual filesystem + file I/O: From FreeBSD.
5) Network stack: from FreeBSD
6) System call API: from FreeBSD, but modified to call into Mach.
7) Crypto stack: from OpenBSD
8) Userspace: from FreeBSD
As you can see, the main things handled by the FreeBSD code are file and network I/O, and the userspace libraries and utilities. However, Apple still doesn't source a lot of code from FreeBSD for these components, because the locking model used in XNU's BSD core and the one used in FreeBSD are completely different. So in general, the relationship between Darwin and FreeBSD really isn't that tight, certainly not as tight as, say, the one between NetBSD and FreeBSD, and the code flow from one to the other is fairly minimal. If you look at where the heavy work in OS X has been going on over the past few years (driver improvements, HFS+ improvements, threading improvements), you'll see that most of that work has been in non-FreeBSD components. In practice, its really not accurate to say that Darwin's model is really different from Microsoft's "shared-source" one, asiding from the licensing issues. For all intents and purposes, Apple does 99% of Darwin development, while Microsoft does 100% of Windows development.
A Mac system that runs comparable to my desktop system (which is only a 2.2 AMD with 2 gigs of RAM) that I spent about 1100 dollars building would cost in the neighborhood of 3000 dollars.
That's not really true any longer. It's true that when I bought my PowerMac, I got a $2700 machine that was a bit less than comparable to my $1700 AMD machine, but the new Intel Macs are a different story. For what I do (compiling), the 2.0 GHz Core Duo in the 20" iMac is directly comparable to a 2.2 GHz Athlon X2. For $1700, the same as I paid for my AMD machine, I get a machine with less RAM (512MB versus 2GB), but with a good 20" LCD, video camera, wireless ethernet, bluetooth, and even a remote.
Now, its important to compare apples to apples here. Most home-built PCs are crap from an ergonomic point of view. They're loud and built with flimsy cases. The iMac, on the other hand, is very quiet and very solid. Since I can't stand computer noise interefering with my thought process while programming, I built my AMD machine the same way, which accounts for its relatively high price. If ergonomics isn't a feature you want in your machine, obviously you can build it for less, but then you're not really comparing the same thing anymore.
Now, it's safe to say that Macs will always carry a price premium. The premium may or may not be worth it to you, depending on how much you like OS X. Since OS X is a software developer's paradise, I consider it well worth the $700-$1000 extra I paid for my PowerMac. However, its also safe to say that with the Intel transition, the premium is going to become less of a problem. What made the premium particularly bad for Macs of the past was the fact that even high-end PowerPC processors were comparable more to mid-range x86 processors. So you'd take a high-end (and priced that way) machine like the top PowerMacs, then have to compare them to mid-range (and priced that way) Intel machines.
With the Intel transition, that variation is eliminated, and your "OS X tax" is basically Apple's larger margin on their hardware. Considering that Dell's margin of ~10% puts the actual price of a $2000 machine at $1800, and that Apple's marging of ~25% puts the price of the same machine at ~$2250, that makes for a premium of only a couple of hundred dollars on most of the price range. That's quite a reasonable premium for a high-end brand and the advantages of OS X.
A.) I can let a 6 year old install software on a Windows system... But I have to train someone who has 20 years of computer experience on how to find their files on a Mac.
Um, what? Installing software in OS X is a matter of dragging a file to a specific folder. Are you telling me a wizard is more complex than that? And findng files is about as complicated as clicking the Finder icon, and boom, there is your home folder! Hell, as of Vista, the user-specific file hierarchy in Vista will be the same as in OS X (root directory) -> Users -> (home directory).
You're wrong. OS X is based on NeXTStep. Now, NeXT Step is itself a BSD derivative --- it used a 4.3 BSD system server on top of a Mach 2.x microkernel, which was itself a derivative of an earlier version of BSD. During the development of OpenStep (NeXTStep 4.x), the 4.3 BSD code was repalaced with 4.4 BSD-Lite2 code (along with lots of NeXT-specific additions), and when Apple acquired the OS to turn it into OS X, the microkernel was upgraded to Mach 3.x, the system server was fused into the kernel, and some substantial FreeBSD components (networking, filesystems), were integrated with the 4.4 BSD code.
So while there is substantial FreeBSD code in Darwin, Darwin is not FreeBSD. Apple still does almost all the development of Darwin, and has evolved the kernel is a somewhat different direction than FreeBSD. Darwin's new fine-grained locking model (which appeared in Tiger) is substantially simpler than FreeBSD 5.x's locking model, it doesn't use the new FreeBSD ULE scheduler, it doesn't use GEOM, it's driver and power management API, contained in the IOKit, is completely different, etc. Apple can still use FreeBSD code here and there, such as the IPV6 stack, updated networking components, UFS improvements, etc, but the core kernel is different enough that the code sharing doesn't extend much beyond that.
Translucency and alpha blending are the same thing. All the effects I mentioned are just uses of translucency to varying degrees. The curved window borders are translucent (with zero opacity --- just an extreme case of translucency), while the menus, etc, are more opaque, but still translucent.
Your original post implied that you thought the definition of translucency had something to do with blurring, while the conventional usage of the term in reference to computer UIs refers to very specific capability --- alpha-blending of window buffers. This term is fairly precise, indeed, even mathematically so, in that it implies a particular blending equation on top of everything else.
Anyway, my point was that if Vista can do it, OS X can do it. Quarz Compositor has access to all the window buffers on the display as a texture. From there, it can leverage CoreImage to use the pixel shaders to perform a blur effect, the composite the result onto the framebuffer. Now, Apple doesn't use blurring in the UI, but that's independent of whether OS X can perform the effect.