Slashdot Mirror

PS2 vs. PC

Even more interesting, however, is the article about the architecture of the Playstation 2's Emotion Engine. I'd suggest that anyone read both of these articles before believing all the claims in that SegaWeb article.

If you look at the design of the PS2 architecture you'll see that it's a good 5 years ahead of where everybody else is. The PS2 was design for dynamic media applications. (3D Games) This is were you have some small loops of code that process a huge amount of data. (Renedering 3D images) If you look at the PS2 you will see you have a very wide data bus thats connected to a bunch of very fast vector units. (The V1 , V0, Emotion engine) If your a geek you need to read the following links. It's really opened my eyes to the power of the PS2. PS2 Architecture VS PC Architecture Emotion Engine Analysis

If you look at the design of the PS2 architecture you'll see that it's a good 5 years ahead of where everybody else is. The PS2 was design for dynamic media applications. (3D Games) This is were you have some small loops of code that process a huge amount of data. (Renedering 3D images) If you look at the PS2 you will see you have a very wide data bus thats connected to a bunch of very fast vector units. (The V1 , V0, Emotion engine) If your a geek you need to read the following links. It's really opened my eyes to the power of the PS2. PS2 Architecture VS PC Architecture Emotion Engine Analysis

Interesting comments.

You may find the DC has better graphics for most titles and Dead or Alive 2, which is on both platforms, looks much better on the DC.

It's not as direct a comparison, but Quake 3 on the DC looks better and runs smoother than Unreal Tournament for the PS2. And while this was true for Q3 and UT on the PC, it's fair to say that the DC Q3 comes closer to the original than UT on the PS2 does, an impressive statement considering Q3 only really pulled ahead on high-end PC's. The PS2 is clearly the more powerful machine as a simple sum-of-its-parts, but half the VRAM and much less ease-of-programming are apparently hurting it quite a bit.

Sony has a terrible software ratio(1:1.8) which makes the $188 hit on each PS2 more difficult.And as you know, the $$$ come from software sales.

Why is Sony losing on the PS2? Easy, the PS2 happens to be one of the cheap(est) DVD player on the market.

Sony has apparently forgotten all the lessons they so ably taught Nintendo and Sega with the launch of the PS1. With the PS2, Sony has copied Nintendo's restrictive licensing, the Saturn's difficulty-of-programming, and both Nintendo and Sega's head-in-the-sand arrogance. Hell, they've even copied 3DO and the Phillips CDi with their hairbrained scheme to turn the PS2--which doesn't even ship with a modem--into the mythical set-top-entertainment-center-information-super-on- ramp of Convergence Past, Present and Future. Instead, as you insightfully point out, they may only succeed in losing a hell of a lot of money selling cheap DVD players to people with little intention of playing games. Sony is obviously betting that those people will justify the high purchase price to themselves as cheap-for-a-DVD-player, and then start buying games on the justification of well-I-already-own-the-console. Of course, in order for that to work, the games have to be fun, which they currently aren't. The question is how quickly they'll become so.

This is going to be a damn interesting round of the video-game wars, perhaps the most interesting yet. Objectively, Sega ought to be in a fine position--decent DC sales, great price, PS2 shortages, online gaming outta the box, and a crop of games which matches the PS2 graphically and bests it in gameplay. But they're losing money, and most importantly, they've lost hype. Hardcore gamers love the DC--but they've already got one. For everyone else, the only thing that's gonna get them to buy a DC is that--as you suggest--they go to the store looking for a PS2 and find out there are none. I'm not so sure that this is the sort of thing you want to build a market strategy on.

And then there's the XBox. So far, MS is playing the role of Sony in the last round--listen to developers, make the machine easy to program, snap up as many big-name titles as you can. Of course the big difference is in timing--the PS1 came out second, but only because Sega rushed the Saturn launch, with disasterous results. The XBox is coming late, which is held out by some as the fatal mistake of the N64. But with the lateness should be a corresponding technical superiority, something N64 didn't have. Plus it'll have a ton of top-tier 3rd party games, another fatal weakness of the N64.

It used to be everyone ridiculed the XBox as misguided, bloated, underpowered vaporware. Nowadays the only place you run into those opinions is slashdot, and less and less even here. Time and Newsweek are still sold on the PS2 hype, but developers appear to have moved on, and regularly gush about the XBox. I'm sure we all hope the latter group is more important in the long run.

And then, of course, there's the GameCube. Well, it's nice, and it comes in cute colors. To me it just screams XBox-lite--more powerful and easier than the PS2, but not as powerful or easy as XBox. eDRAM is some pretty hot technology, but still expensive and difficult to fab. Frankly, I don't trust it in the hands of ArtX any more than I would the Bitboys (Oy!). And I just don't think the rest of the system is going to be up to snuff, especially by the time it launches.

What Nintendo has going for it is some hot properties--Mario, Zelda, Metroid, DK, Pokemon. But while some great games have been made out of these, they're in a shrinking niche of the gaming industry, as the power of technology is allowing video games to become much more complex and appeal to an audience far beyond 9-14 year old boys. Meanwhile, MS seems to have miraculously gotten a share of or stolen outright all the great games which were once reasons to look forward to a PS2--Halo, MGS2, Oddworld, Crash, etc. I've heard EA is about to be signed, if they're not already. About all Sony has left is Square, and we'll see for how long.

So if I had to guess, I'd go with the XBox as the victor, the DC as becoming a small but solid success for a Sega desperately in need of that, the NGC as being the same for a Nintendo with rather greater aspirations for it, and the PS2 as garnering significant marketshare but without earning Sony either the profits or the influence it has apparently decided are inevitable.

But we'll have to see.

Hey, check this out, courtesy of Ars. It presents an alternate viewpoint using different means. I remembered reading this not too long ago. Interesting read. . .and to add a spoiler, it definitely recommends the Fraunhoffer over LAME and BladeEnc.

-s

I know that Xing (AudioCatalyst) doesn't have the greatest encoder, but that's no reason to leave it out...

After all, Ars Technica didn't...

---------

For your information it is not a 128 bit processor but a 32 bit MIPS based processor with a pair of vector units sitting on a 128 bit memory bus.

Actually, you're wrong, too. It's still not a 128 bit processor, but it's a package a 64 bit MIPS III-series chip and two vector units. It accepts 128 bit words, and breaks them down for handling by one or the other of the 64-bit vector units. See this page on ars techinca for more information on the CPU core.

Emotion Engine Resources:

• Chris' Emotion Engine Page
• Ars Technica: Sound and Vision: A Technical Overview of the Emotion Engine

For your information it is not a 128 bit processor but a 32 bit MIPS based processor with a pair of vector units sitting on a 128 bit memory bus.

Actually, you're wrong, too. It's still not a 128 bit processor, but it's a package a 64 bit MIPS III-series chip and two vector units. It accepts 128 bit words, and breaks them down for handling by one or the other of the 64-bit vector units. See this page on ars techinca for more information on the CPU core.

Emotion Engine Resources:

• Chris' Emotion Engine Page
• Ars Technica: Sound and Vision: A Technical Overview of the Emotion Engine

Fortunately for Intel, they didn't have to take any risks, since every single one of the things you mentioned was done by someone else first. Hell, the Alpha alone did all of them before Intel did. Not one of these technologies were "in it's infancy" when Intel deployed them.

The only risk Intel takes in deploying any of these technologies is the risk that Intel customers won't buy them. That's the risk every company takes when introducing a new model. While yes, it means Intel is taking risks, none of the risks Intel takes actually advance the state of the art.

That's just because he came up with a bad list. Despite the fact that there are very few totally new ideas in the MPU industry (just as there are very few totally new software algorithms), Intel has indeed bet the farm (well, bet the product line) on some very radical design ideas, both in the past and the present.

Some were successful, some crashed and burned. One design that was extraordinarily innovative and successful was the P6 core, introduced in 1995 with the PPro. In it, Intel managed to do "the impossible"--execute variable-length x86 code out-of-order, something that was supposed to be only possible with a fixed-length ISA and was even relatively state-of-the-art there. The way they did this was by essentially "emulating" x86 code by decoding it into internal "RISC-like" ops, which could be run OOO. While I doubt this was an entirely new idea, I'm not aware of any previous implementations of it, much less one as wildly successful as the P6.

One design that was a horrid failure was the iAPX432, an MPU spread out over 3 chips which essentially operated in an object-oriented manner, rather than iteratively like, well, every other chip in history. Perhaps a sign of what was to follow was the fact that the 432's "assembly code" was actually built to closely model ADA, the government's ill-fated OO language. The 432 somehow managed to work, but performed a bit slower than mainstream MPUs from 5 years beforehand. Not too many sold. But there is no doubt that here Intel took a huge risk based on a very interesting idea.

Nowadays Intel is engaged in exactly the same "risky" design behavior in an attempt to further the state of the art. The P4 contains several totally new innovations. Perhaps most prominent is the trace cache, an L1 instruction cache which instead of just dumbly storing instructions, orders them safely and unrolls loops, allowing branch- and dependency-free operation for large swaths of code. In addition, the trace cache stores those internal "RISC-like" ops, not x86 ops like a normal instruction cache; this takes the x86->"RISCop" decoder out of the critical path and should result in higher top-clock-speeds and excellent performance on small looped code which can fit in the L1 trace cache--3D engines, encryption, and FFT (i.e. audio/video encoding/decoding, voice recognition), for example. Trace caches are not a new idea; they've apparently been studied quite a bit in the literature. However, the P4 is the first commercial MPU to include one, and that's a substantial engineering innovation.

Another innovation which is, from what I've heard, actually a totally new idea is the P4's double-pumped ALU and supporting hardware. While the idea of different pieces of hardware running at multiple speeds is of course not new, this is apparently the first time it's been worthwhile to implement it on-die in a commercial MPU. More impressive is the fact that Intel was actually able to get an ALU--one of the most studied logic circuits in history--to run at up to 4.0 GHz in current .18 um process technology. Apparently the way they did this is by implementing a new, lower-latency adding technique. This is the circuit-design equivalent of finding, for example, a faster sorting algorithm; it represents a very impressive achievement. While the double-pumped ALU will likely not have as large an effect on overall P4 performance as the trace cache, it should help out noticeably and it's definitely a radical design.

On the other hand, we have Intel's upcoming IA-64 ISA, an attempt to move the VLIW philosophy from specialized DSP work into general-purpose computing. Again, VLIW is not a new idea, and the idea of a VLIW general-purpose MPU is not either. However, the Itanium is one of the first attempts to actually build one (Transmeta's Crusoe is the other).

Furthermore, it represents quite a risk from a performance standpoint. The basic idea behind VLIW is to in effect take the RISC revolution one step further. While the RISC vs. CISC debate is often treated as a fair fight capable of producing one victor, the reality was quite different. (The following is essentially a synopsis of this excellent article on ArsTechnica.) Instead, each was the best ISA philosophy for the prevailing conditions at the time. CISC was the best design choice for its time--that is, up until the early 80's--and "pure RISC" the best for its time--from the mid 80's until the mid 90's.

The main issues involved the evolution of storage capabilities and compiler technology. First a broad comparison of what CISC and RISC actually mean: CISC refers to a category of ISAs in which a new instruction is concieved of to take care of every possible situation. A (made-up) example of a CISC-like instruction is the following:

CRAZY_OP, mem1, r1, mem2

which does the following: load mem1 from memory, take r1 from a register on the chip, compute (mem1 - r1) / r1^2, and store that in mem2. And there actually were some CISC instructions which were nearly that crazy. The RISC philosophy, on the other hand, would break that one operation down into many--one to load mem1 to a register, one to subract mem1-r1, one to multiply r1*r1, one to divide the two, and one to store the result, for a total of...lessee...5 instructions.

What's the difference? Well, like I said, it came back to storage capabilities and compiler technology. Back in the 70's when CISC was the Right Thing To Do, storage was extremely expensive and thus very scarce. If chips back then had used my RISC design, such an operation would have taken 5 instructions to code; with my CISC design, it takes just one. Yes, the CISC design might need to reserve some extra bits in the opcode field in order to code for so many ridiculous instructions, but overall the compiled RISC code is going to take at least 4 times as much storage space as the CISC code. So even if you didn't expect to run into the above situation very often, it made sense to have an explicit code name for it whenever you did.

As we hit the 80's, these storage issues rapidly eased, to the point where it wasn't such a hardship taking 4 times as much space to say the same thing every once in a while. Meanwhile, back in the CISC way of doing things, you actually needed to find some way to make your chip capable of performing all the goofy instructions that might be asked of it. In essence, it's almost like your assembly code is "compressed" to save storage space, and thus needs to be "decompressed" by the chip. This means complicated chip implementations, each trying to do more in each clock cycle--which means lower top clock speeds. The RISC chip may need more cycles to do perform all 5 instructions, but since it only performs simple instructions, it can have a higher clock speed and thus come out ahead.

But there's a problem with this too: people generally like to program in high-level languages. RISC is a low-level ISA philosophy. Thus you need to have good compilers, to be able to analyze high-level instructions and decompose them into all their composite parts for encoding in a RISC assembly language--often a more difficult process than in my example. Again, the compilers of the 70's weren't up to the task; only in the 80's did good enough compilers come along to enable this. In essence, we moved the "decompression" of a high-level instruction to its low-level constituant operations from inside the chip (CISC) to in the compiler (RISC).

Thus, we went from CISC being a Good Thing to RISC being a Good Thing. The main issues were 1) code bloat not such a big deal and 2) move more instruction scheduling duties to the compiler.

Since that time, we've moved from what I called "pure RISC" to what Hannibal in the article I'm summarizing calls "post-RISC". That is, people started realizing that with RISC operations being more-or-less uniform, a good way to make things to faster was to do more than one thing at a time, and that instead of sitting and waiting on a long memory access, etc., you could switch and do other stuff at the time. Thus we got superscalar and out-of-order execution, respectively.

Moreover, we got deeper and deeper pipelines--sort of like assembly lines, in which each instruction goes through several stages, each 1 clock long, in its execution. This means we can clock the chip faster (less to do on each clock cycle), and get overall faster performance (think a fire brigade of 10 people each passing buckets a short distance, vs. one person running 10 times as far between buckets delivered). The problem is that, unlike buckets or trucks, code has dependencies; instruction 2 might take as its input the result of instruction 1, which is still in the pipeline--only halfway down the assembly line, as it were. Thus we need rescheduling logic to keep our pipeline stuffed--our assembly line filled--with instructions which don't depend on each other. Or, instruction 1 might be a branch instruction, which goes one way or another based on its result, so that we don't know "what comes next" until it is completely finished. Thus we use branch prediction, which uses some statistical methods to guess what comes next, and execute it accordingly, while aware that if when we get to the end of instruction 1 it turns out something else came next, we need to go over and do that instead.

The result of all this out-of-order superscalar pipelined "post-RISC" stuff was much higher IPC (Instructions executed Per Clock), but also lots of complicated logic on MPUs to handle all the scheduling and dependency checking and prediction. Theoretically, just as all the complicated logic made CISC chips complicated and slow, all this complicated logic makes today's post-RISC too complicated, too large, too hot, and slower than they might otherwise be. [end summary]

Thus, the basic idea behind VLIW is an extension of the idea behind the CISC->RISC transition. To wit: why not take all this complexity out of the MPU and put it back into the compiler? That way, we can get rid of all the unpleasantness once, at compile time--on the developer's time, not the user's. The way it does this is by trying to find all the parallelism, work out all the dependencies, and predict all the branches at compile time--in other words, to do all the scheduling at compile time. The way it communicates this to the chip, then, is to compile not to individual instructions for the chip to schedule, but rather into prescheduled "bundles"--or "Very Long Instruction Words"--which are supposed to be guaranteed to work well when run together in parallel.

Or rather, this is how VLIW works where it is normally used--in DSP type processors, running programs for which it is very easy to extract this sort of data at compile-time. Problem is, it is much more difficult to do with general-purpose programs, which is why it hasn't been done before. As you might guess, there's just too much you don't know at compile-time for you to get unambiguous scheduling information. Transmeta solves this problem by compiling at run-time, using their code-morphing software, essentially a JIT compiler. The problems with this are obvious and well known: namely, that the JIT compiler uses resources which would otherwise go to running the program, and that you don't get the VLIW benefit of doing all the optimization once and forgetting about it. (The code-morphing software caches, profiles, and further optimizes the code its already run, but it still always running, and doesn't save this information from session to session.) Indeed, you're essentially moving the scheduling problem from one which is done by specialized on-chip logic in different pipeline stages than the execution logic--and thus not competing for execution resources--to one which is run by the general-purpose execution logic; a shaky trade-off at best. On the other hand, by working in software you theoretically get more flexibility to schedule instructions than when doing the scheduling with a chip's fixed logic.

The way IA-64 handles this problem is to have the compiler insert "hints" about which instructions look like they *might* be able to run in parallel, without dependencies; which way a branch is *likely* to go; which scheduling is *likely* to make good use of the chip's execution resources. The problem with this is, as the hints are inevitably going to be wrong, the chip needs its own analogues of much of the scheduling hardware it was trying to get rid of in the first place. In some ways, it's little more than a change in terminology: with OOE designs you have a smallish general register set with a large set of "rename registers", so that each instruction running in parallel essentially thinks it has a full copy of the general register set all to itself; with IA-64, you just have a huge general register set so that each parallel instruction has enough registers to work with.

The problem is, of course, that you haven't done what you set out to do--eliminate complex scheduling logic from the processor. Instead, you've just replaced it with similar but less-well understood versions of the same stuff. The end result is the that Itanium core, far from being small, simple and clocking fast, is huge, complex, unbalanced, and therefore capable of pitiful clock speeds. The die is ~300mm^2--roughly 3 times the size of a P3--yet only has room for a total of 16kb L1 and 96kb L2 cache, less than even a lowly Celeron. (Server level chips like Itanium generally need much *larger* caches than PC chips; Itanium is supplemented with a large off-chip L3 cache, but it is too high-latency to be much use.) Itanium was supposed to launch in early 1998 at 800MHz; it is only now yielding above 733MHz--again, Celeron territory.

Furthermore, we run into trouble from an unexpected place--code bloat. Of course, it's not the same problem as in the 70's, when we used CISC ISA's to keep code small so that they could be stored at all; today's 100GB HD's testify to that. Rather the problem is that *bandwidth* to storage is very often the limiting factor with today's technologies, and that high-bandwidth storage--i.e. on-chip cache--is just as scarce as overall storage was in the 70's. With all its hints and bundling and exception codes to execute if the hints turn out wrong, IA-64 is much more bloated than x86 or RISC code, and thus those not-even-Celeron sized on-die caches are effectively even smaller.

Of course, Itanium has more functional units than the P6 core, and if all these compiling tricks actually keep them full of instructions, it will perform much better per clock. Unfortunately, all indications are that even with the relaxed "hints instead of guarantees" rule, it's still just too difficult for today's compiler technology to keep this monster even remotely well-fed. Intel even had the gall to claim at their recent Intel Developers' Forum that the SPEC CPU benchmarks were "irrelevent" for Itanium's target market, offering instead a (hand-written in assembly) RSA encryption benchmark in which Itanium demolished a Sun USIII. Well, that's fine, except that a very cheap dedicated encryption chip can beat the Itanium at this game several times over for 1% the cost and power requirements. Of course, the SPEC benchmarks run exactly the sorts of programs used in Itanium's target market, and are the most relevent measure possible. And not coincidentally, they are extremely sensitive to compiler quality.

So...to get back to our original topic, IA-64 is another huge risk--Intel has repeatedly called it a "bet-the-company thing"--which incorporates some very interesting, non-mainstream ideas in an attempt to radically advance the state of the art. And so far, it appears not to be working.

Don't worry too much about Intel, though; from all indications, McKinley, the 2nd-generation IA-64 core, should perform just fine thank you. Interestingly enough, it was designed almost entirely by HP engineers. But it also must be emphasized that they have clearly learned from Intel's myriad mistakes with Itanium. (Everything about Itanium, from the pitiful tacked-on caches to the rather unnatural pipeline design--apparently an extra stage needed to be added late in the design process--indicates that this design was a "learner".) Plus, Itanium has been delayed so long that the almost-on-schedule McKinley is due out relatively soon--roadmaps have it as soon as Q4 2001 (dubious), and Q1 2002 might actually be reasonable. McKinley should clock just fine (although not as high as the CISC front-end P4), and has plenty of on-die cache. And in a year and a bit, the compilers might finally be ready too.

So, Intel might just turn this risky strategy into gold. Maybe the "post-RISC" paradigm *will* run out of gas soon, and VLIW will speed past. The point is, for better or worse, Intel's MPU designers are not conservative in the least.

AMD, on the other hand, has never introduced any significant new MPU design techniques that I can think of; instead they concentrate on implementing Intel's designs better than Intel. Indeed, their first PC MPUs had the same names as Intel's--AMD made a "386" and a "486", and possibly a "286" too, I don't remember. The much-vaunted K7 is really quite similar to the P6 core, just with more functional units, larger buffers, more decoders--more more. It's a better version of the P6 (though less power efficient), but it's not terribly innovative. Of course, AMD was in a precarious enough position market-wise that they didn't have the luxury of taking engineering risks. Intel being relatively secure (and percieving themselves, Andy Grove's catchy business-trade bestsellers notwithstanding--as even more so), they can and do experiment with some wacky stuff. Some of it works, some of it doesn't, and for some of it they take their massive market power and force it to work.

Well, the beef with the Pentium II is that it seems to suffer from BSE (bovine spongiform encephelephy a.k.a. Mad Cow Disease), although I doubt that any British cattle was involved. Although BSE infected products shouldn't be imported, I'm pretty sure we'll also see the Pentium II here in Europe soon after the 3rd of May when it is finally released. However, since I wouldn't eat BSE infected beef, I wouldn't be interested in risking an infection of my computer with this CPU either.

...For former Pentium users there's hardly any attractiveness in the Pentium II either. The Windows 95 performance is hardly any better and in some cases even worse than the cheaper Pentium Pro or Pentium MMX. Windows NT users would be the last ones to be interested in the Pentium II, there is just no reason at all to swap the Pentium Pro for a Pentium II.

Well, the beef with the Pentium II is that it seems to suffer from BSE (bovine spongiform encephelephy a.k.a. Mad Cow Disease), although I doubt that any British cattle was involved. Although BSE infected products shouldn't be imported, I'm pretty sure we'll also see the Pentium II here in Europe soon after the 3rd of May when it is finally released. However, since I wouldn't eat BSE infected beef, I wouldn't be interested in risking an infection of my computer with this CPU either.

...For former Pentium users there's hardly any attractiveness in the Pentium II either. The Windows 95 performance is hardly any better and in some cases even worse than the cheaper Pentium Pro or Pentium MMX. Windows NT users would be the last ones to be interested in the Pentium II, there is just no reason at all to swap the Pentium Pro for a Pentium II.

For tech news, I check BBC Tech News, Ace's Hardware, Tom's Hardware , or ARS Technicia. ZDNet has become way to sensational and biased. And all the crappy banners! More like The National Enquirer of geekdom.

For discussions, I check K5 or Rootprompt. And Slashdot. But it's tough to have a discussion here anymore.

I'm sorry to say, but Slashdot, while I check it regularly, is starting to have too high a signal-to-noise ratio. Not enough "discussion" too much "babooey to natalie portman's beowulf cluster of hot grits and penis bird on toast."

It's safer to stay off the main page if I want some interesting discussion. As well, I don't tolerate mistakes in my profession. No matter what I do, I like it to be as perfect as humanly possible. While I know mistakes happen, there have been far too many here, adding to the signal-to-noise ratio, and reducing my faith in accurate articles.

I get my news elsewhere, but I still come back, hoping the old days will return.

I won't spoil it, so go read it.

Toodles,

Nephs

K7s are essentially RISC, and have more in common with a G4 than with a PIII.

Check out the comparison at Ars Technica.

K7s are essentially RISC, and have more in common with a G4 than with a PIII.

Check out the comparison at Ars Technica.

What I really would have wanted to do (1.5 years back) would be to run a dual k6-3 500... Oh well :)

"NextStep has provided a good graphical user interface on top of a Unix variant for 11 years now. Apple bought Next, freshened it up, and added Mac compatibilty and eye candy. I fail to see how that gives them all the credit for it."

How can you deny them credit for this? Apple is really as much NeXT as it is Apple. It has the same CEO as NeXT, and the same person in charge of software, Avie Tevanian. As you can read in his bio, Tevanian was also a principal developer of Mach at Carnegie-Mellon.

This is not the same as Microsoft buying some guys out of their garage because they had developed some widget Bill wanted to assimilate or bury (Apple do this too, of course). The acquisition of NeXT has totally transformed Apple, and not just because of Steve Jobs' return. Five out of Apple's eight-strong senior management team are ex-NeXT.

Many of the people who brought you NeXTSTEP are developing it into OS X. Why should they be denied the credit? Also, if you think the developments are merely cosmetic, you should check out John Siracusa's articles on Ars Technica

"Especially as they have broken some of the nice things in Next, like having both buttons on a scroll bar in the same place."

That's a fair point - you can have this under the current MacOS, so I doubt it will be long before it is grafted back onto OS X, together with a bunch of other useful stuff from both MacOS and NeXTSTEP which is absent from the Public Beta.

I believe Apple and OSX ought to be judged on what THEY claim they're trying to do, instead of being bashed for something this group THINKS they're doing.

Same goes for Microsoft, or anyone else for that matter.

Jobs doesn't make a secret of his core message about the company: "Apple is all about exploring the intersection of art and technology," he said at Macworld in New York. "It's in our DNA." Read that again. ..... Does it say anywhere that they're trying to build the fastest servers in the world, or hope to run spreadsheets better than anyone else? Hell, no. Someday they might do both, now that they're launching a new OS with some serious strengths, but that's not what their first priority is. "Exploring the intersection between art and technology" is what they care about most. For anyone who thinks that's stupid, stop reading now, because this is not the company for you. Fine. Good luck in your chosen work.

For those of you are still reading, try thinking about what he said on it's own terms. It seems to be a consistent and honest statement of his beliefs. I'm assuming that normally intelligent people who need an enterprise server will pick Linux, all else being equal, as most people know that it's stupid to try to drive a nail with a wrench.

Similarly, it seems patently unfair to judge Apple and OSX on claims the company never made. If, for instance, Apple rolled out OSX today and said: "We're going to take on NT and Linux in the enterprise server market with this baby," then it would be fair to take this claim apart on that basis. But they didn't say this, and won't.

Maybe there are a lot of tech-oriented people who've never thought about how technology and design ought to be pulled together, but does that mean we shouldn't ever consider it? Their uncles were the same ones who ridiculed the GUI in the first place, 25 years ago. Then processor speed caught up, RAM got cheap, as did bigger hard drives, and the efficiency arguments didn't mean as much any more. Won't improvments in hardware keep trying to catch up to what software writers can think up? There's always this back and forth, with advances in one area forcing improvements in others.

Another point is that Jobs has called OSX "the future of the Macintosh." Judge it on that basis, not on how much the old OS sucks, would you? This is the first rollout of a completely new (if you don't count the BSD layer) consumer operating system for a long time. How well has the rollout gone so far? What does the OS offer in the way of improvements over the old, and is that going to be enough? Did you read the careful review over at Ars Technica?

If you don't care what happens over in Cupertino and with Macs, you are, of course, free to ignore the thread and move on.

If OSX fails to live up to it's own promises, that may be sad for some of us, but in the grand scheme of things, that's tough luck, isn't it? Call it Digital Darwinism. Only the successful code survives.

...in each category.

Low: Everybody needs more memory. Or you can help save a species.
Mid: Put this in your hand, or this under your desk. Either would please.
If you have to ask: One of these would be nice, particularly for Quake, but I NEED one of these. Really. It could solve a fair number of problems.

Under $300:
Games, of course - Grandia II, Final Fantasy IX, Majora's Mask -
But you're probably looking at gadgits. So I'll say a GameBoy Advanced (yes, I know the US version is a year away, but I can dream), or a Wonderswan (same deal - but I want to play Final Fantasy I-III (the real I - III, not "we'll call IV FFII and VI FFIII! Bwahahaha!").

The other item would be a Playstation One (small footprint) with the LCD panel and a car adapter so I could take it on trips.

$300 - $1500:
One of two things:
A Voodoo 6000 (128 MB RAM, 4 processors, needs its own external power source - can you say Unreal Tournament at 1024x768 4x AA at 100 frames a second? Oh, yes. Check it at http://www.3dfx.com/prod/vood oo/ v5-6000-overv.html
Creative Labs Jukebox http://www.nomadworld.com/products/j uke box/ - 6 gigs of MP3 storage from a name I trust.

$1500+
It took me a little bit, but I'd want one of those Honda gas-electric cars http://arstechnica.com/ rev iews/3q00/honda/insight-1.html - save gas $, save the planet, and stick it to OPEC all at the same time. (Now, if only they'd make an ethenol version so I could help out Kansas farms at the same time...)
John "Dark Paladin" Hummel

There have been several versions of NTFS, the latest and leaked beta qualifies as a JFS.

For more information on JFS, read here.

Of course whether the poster actually knows they're right - well.

• RISC and CISC are old terms referring to the structure of the instruction set. TM x86 processors are definitely no less RISC in this aspect than AMD or Intel x86 processors, since they share the same external instruction set.
• In the somewhat modern meaning of the terms, RISC means that the instruction set is well thought out and adapted to hardware solutions, allowing advanced hardware to run the code faster by pipelining, branch prediction and out-of-order execution. In this sense a TM processor is less a RISC processor than an AMD or Intel one, since the latter carry RISC-like hardware.
• Certain Ars Technica articles ( 1 ) ( 2 ) claim that neither CISC nor RISC processors are developed any more (for the high-end market). They call modern processors post-RISC, borrowing from the advantages of both worlds - CISC hardware has become more sophisticated, whereas RISC instruction sets have become more complex. TM replaced the complex, increasingly troublesome hardware with an elegant software solution. So TM is not post-RISC, which would be the modern interpretation of both CISC and RISC.

The real beauty of TM, which few seem to get in this discussion, is not that they bring RISC to CISC. Intel and AMD have already done that hardwarewise, and it has improved performance tremendously. But they faced new problems with pipeline performance (miss penalties for deep pipelines) and heat dissipation. Classic processor construction could only take them this far. At this stage TM chose to rethink once more the concepts of processor construction. Just like old times' RISC developers saw the flaws and limitations of CISC processors, TM pinpointed the problems of post-RISC processors.

So the TM processors definitely stand a chance. But what are they? What catchy term could we coin to ignite the modern version of the RISC<->CISC wars?

PS
It seems RISC never obliterated CISC, but merged with it instead. (Any dialectic historians out there? :) )
DS

• RISC and CISC are old terms referring to the structure of the instruction set. TM x86 processors are definitely no less RISC in this aspect than AMD or Intel x86 processors, since they share the same external instruction set.
• In the somewhat modern meaning of the terms, RISC means that the instruction set is well thought out and adapted to hardware solutions, allowing advanced hardware to run the code faster by pipelining, branch prediction and out-of-order execution. In this sense a TM processor is less a RISC processor than an AMD or Intel one, since the latter carry RISC-like hardware.
• Certain Ars Technica articles ( 1 ) ( 2 ) claim that neither CISC nor RISC processors are developed any more (for the high-end market). They call modern processors post-RISC, borrowing from the advantages of both worlds - CISC hardware has become more sophisticated, whereas RISC instruction sets have become more complex. TM replaced the complex, increasingly troublesome hardware with an elegant software solution. So TM is not post-RISC, which would be the modern interpretation of both CISC and RISC.

The real beauty of TM, which few seem to get in this discussion, is not that they bring RISC to CISC. Intel and AMD have already done that hardwarewise, and it has improved performance tremendously. But they faced new problems with pipeline performance (miss penalties for deep pipelines) and heat dissipation. Classic processor construction could only take them this far. At this stage TM chose to rethink once more the concepts of processor construction. Just like old times' RISC developers saw the flaws and limitations of CISC processors, TM pinpointed the problems of post-RISC processors.

So the TM processors definitely stand a chance. But what are they? What catchy term could we coin to ignite the modern version of the RISC<->CISC wars?

PS
It seems RISC never obliterated CISC, but merged with it instead. (Any dialectic historians out there? :) )
DS

Speaking of runtime optimization... what ever happened to HP's Dynamo (I think that's what is was called). Run your executable, and it profiles it, and (supposedly) it runs them faster than before... wasn't that originally supposed to be a cross-platform tool (like FX!-32)?

There was an article at Ars Technica a while back... Haven't heard much lately, though. It would be interesting to see what other efforts there are for code profiling/optimization in the same vein...
--

They have discarded way to many Unix conventions for my liking. They have come up with their own method of 'controlling' services.

This actually might turn out to be a Very Good Thing. The OS X config files system appears to be actually more consistent and uses XML extensively. See the excellent series of articles on the DP releases by John Siracusa over at Ars.

To get these services to not start at boot required hacking config files (after 30 minutes of searching to find them).

I strongly urge all wise aged Linux veterans to try to look at OS X with a different pair of lenses; I actually hope that some of these "under the hood" ideas in OS X will find their way into a Linux distribution in the near future.

An article worth reading is Ars Technica overview of MacOS X DP4. It explains why they changed the paths compared to other *nix and why it's good. (Normal *nix paths are available via symbolic and hard links I think)

Well, there is some truth to Darwn being monolithic. It's essentially Mach with a BSD system sever. Why you'd do that, I have no clue, since one of the benifets of a microkernel is that severs are independant. With Mach/BSD, you have to problem of system complexity due to the monolithic design, and you have the problem's with overhead that Mach brings with it. Silly really.

The BSD subsystem is in the same address space as Mach, but all of Mach's interfaces are preserved. This is much faster than a user-level BSD subsystem, and it does not sacrifice the modularity of Mach's native interfaces.

More information is available here.

Hm... I suspect this was "inspired" by a post over at Ars Technica. Their article links to this page as well, which has a review of Casio's wrist watch with built-in digital camera. It's pretty cool, too. 20 kpixel 16-level grayscale, 100 pictures storable in the watch. Syncs over IR to a serial-port connected mini-dock thingie. Not comparable in power to IBM's Linux watch, and it doesn't run Linux, but it's still a very cool thing to have on your wrist, IMO. Being a consumer product (~$200 in the US), it has seen a bit more design effort, too. ;^)

The graphics engine uses several different methods to display things; bit-mapped graphic and vector elements are easily used in the same screen/window elements. If you want a full-blown explanation of how the imaging engine works (it's pretty cool) head on over to this article about the OSX display system at Arstechnica

I gotta agree, (apologies to the authors) this article is really quite lame, even though I appreciate what it's intentions were, namely informing computer enthusiasts about the cooling capacity of various fans. However, this subject was covered much more thoroughly in a more well-written and humourous piece on Ars Technica, it's either a full piece comparing fans or just what's in their product reviews section.
I concur with Brento, I really don't think this merited being posted on Slashdot either.

----

Hannibal at Ars Technica wrote a good article about it:

Thus the "RISC vs. CISC" debate really exists only in the minds of marketing departments and platform advocates whose purpose in creating and perpetuating this fictitious conflict is to promote their pet product by means of name-calling and sloganeering.

The article is available here.

--
"Choose a job you love, and you will never have to work a day in your life."

on ars (the ones at the bottom are broken and point to part III), so here they are :

part I

and

part II

these are really good, and very educational! :)
...dave

on ars (the ones at the bottom are broken and point to part III), so here they are :

part I

and

part II

these are really good, and very educational! :)
...dave

Interesting. I saw some links to this waaaaay back on Ars Technica last year when this company was just getting started. Even then they had a halfway-working prototype. If you think the Solotrek is cool, check out the DuoTrek, which is almost insanely cool with a pressurized cabin and 4 different vectorable engines. No word on projected costs yet, unfortunately.

Email me.
Don't trust anyone over 90000.

Sun has been designing their own chips since the Sun 3. They have designed a neat new processor (ps. anyone else - it really is neat, check out that link). The MAJC processor is in no way tied to running Java code. It is just a neat way at getting hardware to support multi-threading better.

But let's judge Sun on their history. Look at Sun's history with chip production. Look at the bios they use: OpenFirmware. Look how they have spun control of the sparc architecture off into Sparc International, to make it a truely open platform.

Then look at MicroSoft's track record. Do you doubt that M$ will be trying to gain monopoly control over WebTV devices, in the same way they have captured the desktop market?

I really don't see any point in your comparison.

cheers,
G

3) It's got a brutally powerful custom 3D graphics chip [called Flipper] from ArtX, which works intimately with the Gekko processor for maximum efficiency. Developers working on the console are allegedly having no problems pushing nine million polygons at 60 frames per second with preliminary benchmark tests.

You sound technically astute enough to know this, but I'll state it for anyone else who might be reading. Even if the Terms of Service for RoadRunner say you can't run multiple computers, there's really no way they can stop you. Install a LinkSys router (there's a review here) between your computers and cable modem, and it will act as a proxy. RR will perceive the router as a single machine. Short of coming out and inspecting, RR isn't going to be able to tell how many real computers are on it. And if they give you any static, tell them it's a hardware firewall to protect you from the hordes of crackers who are trying to penetrate your system (a true claim by the way; the router can be configured to refuse all incoming connection attempts, which is a good idea). I have Cox @Home and this is exactly what I've done.

Interestingly enough, I just checked out Arstechnica and saw the following headline: Stress-reducing games. Could this be a new genre of beneficial games?

It was posted on Ars a few days ago. I subsequently reported it, but got rejected. Figures.
--

There was talk of a company already in the process of porting X to MacOS's Aqua. I tend to prefer native all the way though I guess it might be useful.

The Ars Technica RAM Guide is a good place to start for the technologies that are around now (SRAM, SDRAM, DRAM, etc.). Ars also has a story about MRAM, which links to this Wired article describing IBM's work in the field.

The Ars Technica RAM Guide is a good place to start for the technologies that are around now (SRAM, SDRAM, DRAM, etc.). Ars also has a story about MRAM, which links to this Wired article describing IBM's work in the field.

• DDR vs. Dual Channel RDRAM at InQuest.
• Very early comparison article (also at InQuest): DDR vs. Rambus A Hands-on Performance Comparison
• arstechnica's RAM guides: part one, and part two.
• Couple links from Tom's: Performance Impact of Rambus and the famous Dissecting Rambus
• And a pretty good MRAM PDF

• DDR vs. Dual Channel RDRAM at InQuest.
• Very early comparison article (also at InQuest): DDR vs. Rambus A Hands-on Performance Comparison
• arstechnica's RAM guides: part one, and part two.
• Couple links from Tom's: Performance Impact of Rambus and the famous Dissecting Rambus
• And a pretty good MRAM PDF

I assume that you're talking about Windows File Protection, which replaces system critical files if they're changed. We're talking about system administrators here, not home users. I'm quite sure they'll know how to get around it.

As a matter of interest, whats your take on Crusoe's VLIW instractions ? To what extent can the problems with VLIW be circumvented by running the compiler at run-time ?

My initial guess would be that you can do it to some extent, provided your compiler is sophisticated enough, and you're prepared to compile several versions of the same source for different input data.

My guess would be similar--that, by looking for dependencies at run-time instead of compile-time, Crusoe has a much better shot at generating fast code and keeping the CPU small, cool, and simple. After all, with their approach, they are successfully able to do what IA-64 can only promise: move all the complexities of instruction scheduling from hardware to software.

Or are they? Because Crusoe (the hardware) is a straight-up in-order VLIW chip, its runtime compiler is actually doing two things: recompiling compiled x86 (or whatever) instructions, and scheduling them. Most of the criticism levied at Crusoe's approach focuses on the first half of this equation, and proceeds along the lines that "JIT is a bad idea, because it's why Java is so slow." As it turns out, I couldn't disagree more. For one thing, much of the reason Java is slower than C/C++ is because it is safer and more OO--it runs its own garbage collector and forces everything to be an object, amongst other things. For another, it's not actually slower! The newest Java JIT's manage to generate faster code than static compilers in many cases--and well they should, because they know more about the machine they are compiling to and the most common critical paths through the software than a static compiler ever could. Indeed, HP is working on a runtime interpreter which will speed up almost any precompiled code.

The reason JIT's can work so well is because they only need to compile the code once, then sit back and profile it, recompiling only when necessary. In other words, they incur a lot of overhead at first, but pretty much stay out of the way afterwards unless they'll really help out.

Now on to the second half of Crusoe's compiler--the scheduler. As I mentioned before, this sounds like a good idea--taking some functionality off of hardware and moving it into software. But when you think about it, you realize there's no such thing as "taking functionality off of hardware and moving it into software"--after all, the "software" still needs to execute on the same hardware!

What you're actually doing, then, is moving a function from having dedicated on-chip hardware performing it to having to be run with normal general-purpose hardware. This still has the very real benefit of making the chip a lot simpler, but now you've added a scheduler that needs to take clock cycles from the code it's trying to schedule.

The big question, then, is how much can the scheduler be like the compiler--that is, just doing its work once and then only stepping in when necessary. If, by moving the scheduler from dedicated on-chip logic to software using general-purpose logic, you make it able to do that much better, then it may be a significant design win. If, however, the scheduler needs to do anywhere near as much work as it would have as dedicated on-chip hardware, you're going to end up losing speed.

Which of these is the case? I have no idea. Obviously, a lot of very smart people (Dave Ditzel, etc.) thought the former. On the other hand, Dave Ditzel is reportedly the one responsible for keeping Sun's chips in-order while the rest of the world moved to out-of-order; a quick comparison between an Alpha 21624 and an UltraSPARC-II (or even the upcoming UltraSPARC-III) shows you who was right on that one. (Hint: not Dave Ditzel.)

What we do know is that Crusoe is a lot slower than Transmeta originally thought a runtime interpreted VLIW processor would be. There have been strong reports that they originally envisioned their processors would be able to beat leading-edge x86 chips handily, and only scaled back to the low-power market once their original benchmarks came back disappointing. Even at the low end of the scale, they're attracting a lot of ridicule amongst chip designers for trying to "reinvent the benchmark" because their chips can't compete. I happen to believe that (work/time)/power is a useful benchmark for the mobile arena; still, there's no denying that Transmeta would rely on traditional benchmarks if they could. Furthermore, it looks as if several chips may end up being able to compete with Crusoe even on (work/time)/power--StrongARM's, the much-maligned Cyrix III, and various other low profile simple RISC chips coming out of the woodwork to compete for the "mobile embedded" market.

So, while I would very much like Transmeta to succeed, so far--just as with IA-64--there's little indication that it's more than a bunch of hype. Perhaps after a disappointing first iteration, VLIW will get its kinks worked out and become the standard general-purpose CPU design philosophy of the next couple decades, just as RISC has been for the last two. (And yes, modern x86 chips are designed according to the RISC philosophy, even though the x86 ISA is CISC.) However, I have to say I doubt it. Looking ahead, all the badassest designs of the future (MAJC, Power4, 21464, SledgeHammer) seem to be moving towards keeping the dynamically scheduling RISC architecture and adapting it for CMP--chip level multiprocessing.

But, as always, only time will tell.

You go girl!

Here's a link to an article at liberzine (originally posted at ars-technica). It's a good read. For those too lazy to follow the link here's the quote posted at ars:

The artist once again known as Prince was onto something when he sold his five-CD set "Crystal Ball" exclusively on the Web without the help of record companies, distributors, or record stores. On his website, he advertised the album and told his fans he would release not one song until he had 100,000 pre-orders for the entire record. He sold 250,000 copies and kept 95 percent of the revenue which industry experts estimate at $5 million.

Because recording artists only get 10 to 12 percent of a CD's retail price, selling directly to the fans is a boon to them. "We got paid!" Prince said, "More than for the last five to six albums on Warner. It's straight-up money, and the check's on time, not quarterly."

Not really.

There is a difference between the x86 architecture (actual silicon), and the x86 ISA (more like an API).

The actually technology behind x86 processors has moved one, and updated. Transmeta is, prehaps, the most extreme example of this, but all modern processors use microcode to 'emulate' x86 (Or, at least, the least commonly used instructions).

So, what has happened is that the 'good' instructions have got faster, but the old cruft, whilst it still works, is slow. Like, I could probably write out some Z80 machine code, and expect it to work on a PIII. But not to maximum efficency.

This is the curse of bakwards compatability.

Ars Technica have a review of this here.

A new architecture could probably do many things better. But would it be sufficently better to make the cost of getting _everything_ rewritten?

Market forces suggest not. (See the Alpha - newer architecture, but not exactly everywhere).

I don't know about Wired, but the Ars Technica article dealing with that can be found here.