Posted
by
Hemoson Tuesday August 14, 2001 @06:32PM
from the believe-when-i-see-it dept.

PowerMacDaddy writes "Over at SiliconValley.com there's an article about an Ausin, TX startup named Intrinsity that has unveiled a new chip that utilizes a new logic process with conventional fab processes to acheive a 2.2GHz clock rate. The company is headed by former Texas Instruments and Apple Computer microprocessor developer Paul Nixon. The real question is, is this all FUD, will the real-world performance be part of The Megahertz Myth, or is this thing for real?"

The question is what instruction set? If it's custom, then they are introuble (unless they expidite work on ports of Linux, GCC, X, etc). If it's instruction set is based on something current but not quite mainstream (Alpha, M68k) then they will be in decent shape. If it runs the x86 (IA-32) instruction set, then they've got a good chance. If it is something else (IA-64 or x86-64) then I'm not quite sure. But of those two, I think they would have a better chance if they went with AMD's x86-64. But whatever the instruction set, I think that we've seen that an easy way to get into the market fast is to embrace Linux and other open source projects head on. Transmeta works great (it supports IA-32 and can run Windoze, which is part), nVidia has done great because of great hardware and IMHO Linux support. ATI could have cared less, but then they got their act together, suppored Linux, and they are doing great now.

According to the EETimes article pointed to elsewhere in this thread, the instruction set will either be MIPS or PowerPC, with the most likely nod being MIPS.

One place MIPS sees a huge market penetration is in networking equipment, especially Cisco routers. If Intrinsity can clock up to 2.2GHz without massively increasing power consumption and heat dissipation, I could see Cisco's high-end routers using the hell out of MIPS CPUs using that technology.

Is this company having an IPO anytime soon? I think they are trying to cash in on the megahetz myth with unwary investors. They push the story now, have 2 or three follow up stories repeated by news organizations who don't know any better, and voila!, they have a ready-made blip for their first few days of trading.

Notice, the article is quietly misleading people who read it into thinking this chip is somehow compariable/compatible with x86 instruction sets... like they have somehow trumped Intel to the 2.2 gig mark, the same way AMD trumped them to the 1 gig mark about a year ago.

Hoping this comes to desktops next year....or at least the threat comes to the desktops. Its first products will be designed to control high-speed communications equipment. High speed as in what? Telecom/cable quality? Or professional networking material? (just had to put that there....most people dont read the article. Im usually one of them lol)

IF this does come to desktops.....that is good. More competition = lower prices. But, lots of issues that are still unclear. What kind of packaging will this be in? Will it require a proprietary motherboard? If it does.....well......im sensing that this wont last too long. Intrinsity's test chip achieved faster performance using conventional methods, where other chip makers have generated chips running at 400 to 500 megahertz, or about one-fourth as fast as the Intrinsity chip So whats this supposed to mean? Maybe they should make that clear. Is that saying that any chip over 400 or 500 Mhz uses special manufacturing techniques. Now that would be the majority of chips......so how can that be special then?

Also.....Much of Intrinsity's work has involved making improvements to a fundamental building block for processor chips: the logic circuit. Intrinsity relies heavily on a faster but trickier type of circuit, called dynamic logic, than do conventional processors. Dynamic logic circuits can handle more complex functions with fewer steps than static logic circuits So does this mean specialized applications/OSes? Not worrying about linux....know it will be ported. But if this needs a special OS, and special new (read expensive) applications......think it will go under.

Just take a normal processor and put an inverter ring off to the side, running at 100mhz, and connected to nothing but power and ground.

Back in the 60s, the power of a radio was measured by the number of transistors. That is, until one radio company put hundreds of useless transistors on their board and didn't even wire them up. After that, radios started getting measured on real abilities like quality of sound. Maybe computer marketting will catch up some day, marketting meaningful numbers: minimum FPS in Quake 3!

What makes you think that something created by Apple and posted on their site is anything other than PR material and FUD? Just because it denounces one of the Slashdot "Great Satans" (Intel) doesn't neccessarily mean that it is anymore true than Intel marketing claiming that bigger Mhz == better.

And honestly, just because the G4 does better on some obscure Photoshop benchmarks really doesn't make up for its lack of scalability (as compared to RISC chips like the UltraSparc II and II) and its lack of good performance in real world applications (as compared to AMD and Intel x86 chips). Please stop the spread of pro-Apple FUD now.

Good point that slashdot should have pointed to, say, the ArsTechnica article on the advantages of the PPC architecture instead of the Apple propaganda. Despite that, no one can doubt that there is a "Megahertz Myth" to a great extent, though perhaps not the the extent Apple suggests. Look at the AMD vs. Intel race right now - people assume that the fastest p3/4 is faster than the fastest Athlon without actually looking at performance results.

Slashdotters love Intel, not so long ago these boards were full of, "look at my cheap overclocked dual-celeron system!"

The Ghz myth (im updating it a little here) is true and Apple makes a point. I would think average consumers would be more comfortable with an Apple link than say Joe Blow's home made linux based benchmark tool. I'd rather refer non-techies to an Apple page than to something a bit more technical, especially if they're considering buying an Apple.

Actually, Celerons (specifically) have very little L2 cache. All Intel chips have too little L1 caches (32KB? That's SO 1998!) Also, a 400MHz G4 costs more than a 800 MHz PIII, and STILL won't run faster than it in most cases.

Not if the patent on the chip manufacturing process is protected. remember, they crated this chip with a fab that was designed to prodec 400 MHz chip. Imagine, if you can, being able to prodeced 8GHz chips in 18 months using the same fabs that they use to create ~1.5GHz fabs.

As the space between the lines in the article say: This won't be for desktop computers, yet...

There is an obvious problem that people, keeps forgetting; RAM-speed. The RAM (and mainboard) can't supply the CPU with enough data to process fast enough. Anyone care to elaborate this with some math and tech info, maybe some predictions on RAM vs. CPU-bus speed development?

Well, I think we could really get to enjoy bumping a 1.4 GHz Athlon to 2.2 GHz once there start to be motherboards with dual DDR channels (4.2 GB/s)

There is still a latency problem, but intelligent caching and compiler design can mitigate that problem, especially if there is a bandwidth surplus available for speculative fetching.

Eventually, to conquer the latency beast, we will need to move more memory closer to the CPU. To do that is going to take moving to serial interconnects for lower pin counts, and reducing the physical footprint on the mainboard.

Unfortunately, as RAMBUS found out, running several hundred MHz over a motherboard trace is difficult. There is noise from other channels, stray capacitence, that sort of thing. This is especially bad if you use a multi-point bus systems. My guess is that eventually we will have to move to a point-to-point serial memory bus. This has the advantage of maintaining low latency, while scaling bandwidth with the number of memory modules.

Eventually, to conquer the latency beast, we will need to move more memory closer to the CPU. To do that is going to take moving to serial interconnects for lower pin counts, and reducing the physical footprint on the mainboard.

I'm not sure that switching to a serial system would help enough. While you could clock it more quickly, you'd still have a hard time matching the bandwidth of a many-line solution. This could ironically result in longer latencies, because despite the higher clock speed, you'd have to sit there and wait for all 32+ bits of the missed word or 128+ bits of the cache line to be transferred before resuming operation.

IMO, a better approach might be running many shielded lines in parallel transmitting data with self-clocking codes. This allow faster clocking by removing the need to keep all lines in synch with each other; data could be rebuilt in buffers at the receiving end.

Regardless of the bus implementation, you'll still likely be limited by the speed of the RAM used.

The final solution to all of this will probably come when we can put a big enough L3 cache on a die to hold the entire working set of most programs. That will give us a short, fast, wide path to L3 memory. Main memory will only be accessed for streaming data or for random accesses to huge databases. In the first case, a high-bandwidth, high-latency bus is acceptable. In the second case, I doubt anything we do will overcome latency problems.

The only way I can see to do it, is to integrate the RAM with the processor, hence you will not have a CPU in your system, just a lot of processing nodes on a bus or series of busses, need more CPU, add another PRAM (Processor-RAM) module. need to do lots of floating number work?, add some FPRAM, RAM with extra FP units.

This has been tried. It didn't work very well. There are a few problems:

Your inter-processor communications bandwidth is low.This is a serious bottleneck for many tasks.

N-way SMP performs worse than N-times-faster 1-way.Amdahl's Law and coherence operation overhead both conspire to bite you on this. Amdahl's law, especially - you can't parallelize all tasks.

And the main reason why processor+RAM modules haven't taken off:

A processor+RAM scheme is functionally equivalent to an ordinary SMP system with no main memory.An ordinary SMP box already has memory tied to processors - the processor caches. Add main memory to your multi-module machine, and you have something that looks suspiciously like an ordinary SMP box with big L3 caches made from DRAM.

For really, really large systems (hundreds of modules or more), this approach is still used (look up "NUMA" for more information), but for smaller boxes it doesn't make a lot of sense.

The real question is, is this all FUD, will the real-world performance be part of The Megahertz Myth, or is this thing for real?"

It doesn't matter if it is real or vapour, it will still fall prey to the "Megahertz Myth". Maybe someday, people will understand: non-similar architectures can't be compared by MHz alone. And even most similar arch's can't be compared via MHz, as the Intel v. AMD war will tell you.

It is even worse than that! no single metric will ever give you the whole story.

Actuall the article has little to do with clock rate comparison the way you're thinking of it, it has more to do with manufacturing, and core improvements which could possible raise the MHz across the board. I'll wager they'll try manufacturing chips, but when that fails 1 of 3 things will happen:
1)they liscese the tech, which is what they should do from the begining.
2)AMD or Intel will buy them
3)AMD and Intel (independently) will gear up there marketing drones, and this chip will fade from memory.
what we need is a testing algrythem that all processors use. then we can rate chips as "it completed the Moffitt algorithem in 1.5 minutes!".

Compare actual performance, which means putting third-party applications onto demo computers at retail locations, and timing complete workdays and/or complete tasks in major applications. Apple does both of these, yet somehow they are depicted as cheating because they don't just offer the customer a range of beige boxes at 1.6, 1.7, and 1.8GHz along with a spec sheet of compiler shootouts. I have never seen computers demonstrated with actual applications outside of the Apple Store. To me, that just says that Apple has nothing to hide. If you don't believe Apple's performance demonstrations, go to an Apple Store and use your own media and see what results you get.

Well, a better measurement than MHz is MegaFlOps. Not great, but better. For some purposes it's even the dominant measure of performance. Once it gets built into a system one can measure kernel compiles, or disk-to-disk copies to get other figures of merit, but for the CPU itself, MegaFlOps, MegaInOps (usually closely correlated with MHz), and MegaBranches are the main relevant figures. We always used to use MegaFlops, but the importance of that is highly application dependant.

I have run many of my own benchmarks on Apple's machines. Apple blatantly lies about their performance (we're way past distortion here) and everybody knows it. A PowerPC G4 chip is _about_ 15% faster per clock than a Pentium III, on both fp and int. The P4 is actually slower than a PIII per clock. Apple _could_ claim that their new 867mhz G4 is the same speed as a 1.3ghz P4, without distorting too much.

If you pick a proper algorithms, one that tests many results,gearing a proicessor towards that would have the effect of improving the cpu as a whole.
wouldn't 667 be that guy across the street from the beast?

Rice rockets can go nice and fast, if they're GOOD ones, you just have to drive them right. American sports cars aren't clearly superior, they're 2 different approaches to sportiness, so don't act like your personal favorite is the only valid approach.

This product looks like a way to create extremely fast logic that approaches the performace of dynamic logic. It looks like it would be used either to make FPGA or CPLD devices, or full custom logic (the site isn't clear on this). They claim this could be used for any high performance logic (which would imply it could be used in processors). Their site is extremely short on details and it looks like this product could be vapor, especially given the fact they start with a Flash animation...

This is fantastic! Hopefully they will be able to live up to the hype unlike Transmeta. Motorola and Intel spend billions is new plants and manufacturing processes, and then a small Austin company comes into the market and will shock everyone.

Amiga-like technology lives on.The custom chipset in the A1000 also used precharge/evaluate dynamic logic with a 4-phase clock. 'course it was only clocked at twice NTSC color-burst frequency, not 2.2 GHz...Actually this was common design methodology in many 4 to 8 micron (not 0.4 or 0.8!) NMOS chip designs of that era.

In a nutshell this is saying "Someone said something, but it might be bogus, and the cycle speed really doesn't mean much anyways.". Alrighty then. This is like a "nothing to see here, move along!" type articles.

In a nutshell this is saying "Someone said something, but it might be bogus, and the cycle speed really doesn't mean much anyways.". Alrighty then. This is like a "nothing to see here, move along!" type articles.

Except in this case there isn't even a really cool, splattered dead guy to stare at.

What's so great about 2.2GHz? Intel is selling 1.8GHz processors right now, will be launching 2.0GHz processors within the next two weeks, and there are Pentium 4 processors -- both within Intel and outside in the hands of overclockers -- running at 2.2GHz or higher already. (And note that the ALU is double-clocked, ie running at 4.4GHz).

If this story was two years old, it might be significant... but it is far from revolutionary right now.

If you read the article, you would know what the big deal is. If thay can scale this process to the current chips, we could see 8GHz chips.
the big deal is they took a method thats used to creat 400 MHz chips, and created a 2.2 GHz chip.

The eetimes article
http://www.eetimes.com/story/OEG20010813S0060
makes it sound like this thing is targetted more towards the embedded market, where (so the article says), the top chips are running at 500MHz. Not sure why they wouldn't try for a desktop pc solution...?

The multiplier is just the difference betweent the CPU speed and the bus speed. An AMD T-Bird 1.3 is actually clocked at 1.3 GHz, but a divider makes the bus speed 266 MHz. The multiplier just specifies how much faster than the bus the CPU should be clocked, its not some trick that speeds up the CPU. Besides, a 2.2GHz bus would be *really* interesting.

From memory 8080s hade some dynamic nodes - the upside is that you can squeeze some extra gate delays out of some circuits (dynamic carry chains are a good example) - the down side is a chip with a MINIMUM clock speed - which makes test (scan and ATE etc) much harder - those expensive testers we test chips with just don't go that fast.

Given that net delays are becoming the gating factor in big chip designs dynamic logic seems to me to just be a sideshow - unless the long wires are themselves the dynamic nodes (transmission lines with solitons moving on them?) now that would be interesting...

Potentially much more interesting IMHO is clockless asynchronous logic - but CAD tools just aren't up to supporting this methodology (oh yeah and the synchronous clock based mindset is pretty entrenched too).

Charles Moore has made several 'clockless' (well, self-clocked) asynchronous CPU designs [colorforth.com] and created his own CAD tools [colorforth.com] to do it. He is able to do this by keeping his designs very small and simple... but they are quite fast. Prototype chips of one of his earlier designs are available from Ultra Technology [ultratechnology.com]. So far he has been backed only by small companies, probably because he is ten years or so ahead of conventional system designers.
--
Mike Losh

What is dynamic logic? How is it different from conventional logic wired together with different types of gates?

Both dynamic and static logic use logic gates or blocks that are wired together. The difference is in how the gates are implemented internally, and how they pass data back and forth.

CMOS is a good example of static logic. It uses pull-up and pull-down transistor networks to make sure that outputs are always strongly asserted. This makes CMOS gates big and makes input capacitance larger than it otherwise needs to be. But, it's well-understood, has a few attractive features, and has a whole slew of design tools built for it.

Precharge logic is a good example of dynamic logic. It uses the parasitic capacitance of the output line to store the output value. The output node is charged up on one half of the clock (precharge phase), and left floating on the other half (readout phase). During the readout phase, the inputs are asserted. Inputs are fed into a pull-down transistor network that drives the output low if it should be low, and leaves it alone if it should be high. This style of logic takes up half the space of CMOS logic, has half the input capacitance, and has stronger driving capability (NFETs pulling down typically drive 2x-3x more strongly than PFETs pulling up). This means that if you play your cards right, you can make precharge logic circuits that are faster *and* more compact than CMOS logic circuits. The downsides are that designing and verifying precharge logic is a royal pain, and that you have to have a clock input into the logic block.

The article describes a more complicated dynamic logic scheme with a four-phase clock. These kinds of schemes have been floating around in research literature for years, but are usually not used because of the greater complexity and fewer tools available.

Or is it moslow? Anyway, there is a program you can use to run games slower. Like... "moslow 10 ultima4" runs ultima 4 at 10% speed. One test of how well a game is programmed, though, is whether or not it needs moslow after 10 years. Games like Doom, Commander Keen, and Prince of Persia all run fine without moslow. Ultima 7 is a different story...

i tried moslo, but it has(had?) the problem of running semi-jerky in most games that i was interested in. example: it worked fine with wing commander ii, but the game was so jerky that it was unplayable anyway.

I friend and I made a small video game, and being the better programer than me - my frind made a bit of code that estimated the speed of the computer and added a delay loop to the game to slow it down.

Fast forward to Today

We lost the complete source code, and our computers are so darn fast that the bit of code that estimates the speed of the computer over-runs it's 16 bit Int slot. The game now hangs hangs.

So we are forced to run our game in Windows to slow it down. It works half the time - it depends on the time slicing. Recently our computers are getting a bit to fast for even that - so we might have to move to an emulator.

The smart thing to do would be to fire up the hex editor and edit the cose, but that would be *cheating*

Been there. Crappy dos game. Polled the clock until it fell over. The clock precision was crap so I had a slight hitch. Also wasn't taking into account the execution time of the *real* code so when I moved to a 386 (from an XT) I was like.. "damn this is fast"

The better approach for your problem is to use the OS's delay function, if you can. (under unix, try nanosleep() or select() with all the fds fields cleared. Sleep() should work on windows.) You free up the processor for other tasks, you don't have to do that speed-estimating crap, and uh you don't hit yer bug.

I would assume you figured this out but you said your other friend who was smarter than you wrote the code:-).. nice story.

Dosemu under Linux has better slowdown capability than Moslo.exe. I have successfully played 4 or 5 of the elder Ultimas and they seemed to run decently with the artificial slowdown.

One project I worship is http://exult.sourceforge.net which has rewritten the Ultima 7 engine with timer-based animation, etc. It is *so* cool. Even if you're not into Ultima games, you should check out the project.

Read the link. The pipelines are smaller, meaning the processor runs more efficiently, crunching more numbers. RISC architecture still can whup the P4. Do you read the P4 specs? It is so held up in legacy technology and backwards compatibility that it just wastes precious time and power cycles.

The eetimes [eetimes.com] article clarifies. They are designing chips using dynamic logic which has the disadvantage of eating up significantly more power. It is actually fairly common to use dynamic logic in chips, just not on a wide scale where power is more important than transistor density or speed.

x86 chips are not simple, and creating a dynamic logic design is not likely. The company seems to have very good background in automatied design tools, but chips on the scale of x86 CPUs are not created in automated tools, they are created by hand and optimized (like assembly coding to the software guys)
"Intrinsity's bare-bones test chip operates at 2.2 GHz..." This is not that impressive on a bare bones chip. They haven't even created an ALU capable of that speed. Nevermind a full CPU. This company also doesn't have any fabs, so they will be at the disadvantage Cyrix and AMD were at in their youth.

Overall, they aren't likely to be making x86 CPUs any time soon. PDAs and laptops can't handle the power draw, so I'm not sure where that leaves them. Maybe they should team with Transmeta [transmeta.com] to solve their power problems.:-)

The company's test chips are fast. In an embedded market where the speediest MPUs push 500 MHz, Intrinsity's bare-bones test chip operates at 2.2 GHz in a 0.18-micron process with aluminum interconnects.

No copper interconnects. No.13-micron process. These are things that I (as a non-chip engineer) can understand. Is this going to improve my life? Only time will tell. But I for one like technology for the sake of technology.

The real news here is that the 2.2GHz speed was achieved using a relatively common silicon process (0.18micron, aluminum interconnects). Intel,AMD,and others are achieving higher speeds (~2GHz), but with much more developed processes (.12micron, copper).

Intrinsic claims to have developed a new way to design and fabricate high speed logic using some older ideas and this could be a significant achievement.

Does this mean that Intel, etc will be able instantly make 4GHz chips? Nope. And as we all know, the speed of the chip isn't a great measure of it's performance.

By the way, that siliconvalley.com article was pretty weak. Did they try to omit as many details as possible?

Intel's Pentium 4 which is currently running at 1.8GHz is fabricated on a 0.18 micron 6-layer aluminium process too. Neither AMD nor Intel are selling 2GHz processors currently and no one is using 0.12 micron. There's an industry shift towards 0.13 micron, but it's not well established and currently only some Pentium III CPUs are using it.
Intrinsic claims to be able to synthesize quad-phase dynamic logic, and this is interesting, but this is something that is present in CPU's already, and it certainly has it's downsides. If you have no latches, verification is very hard. Timing compution is difficult since many tools are optimized for 1-clock static, not 4-phase dynamic. Also, dynamic will be harder to implement in lower process levels due to the higher leakage current (Ioff). This will force up the size of keepers on the interstitial nodes, which will offset the speed advantage while dramatically increasing power.

I took a look at the web site referenced in this article and saw Steve Jobs talking about how the 800 Mhz G4 was faster than the 1.7Ghz Pentium 4. My question is this: what OS was running on the Pentium for? Was it Windows (known to be a resource hog) or a Unix/Linux OS? My guess is that running a better OS would give faster results to the Pentium.

Here is a challenge for Mr. Jobs: run the same Linux distro (ie, Red Hat for Intel and Red Hat for G4) on each machine and then do the bench marks. And while he's at it, try this new micro-processor for speed...

Myth #1: The Internet is Too International to Be Controlled:
TechReview's argument: Safe havens typically don't have enough pipe to host Napster volumes of data; and, to deter law-abiding companies in the "goodguy" international community from dealing with these outlaws, you will be punished with asset forfeiture if you so much as look at them.

My counterargument: The first point is invalidated by the eventuality of distributed networks being more efficient with that volume of data anyway (think anonymous, dynamic akamai), and the second only requires that the "outlaws" be self-sufficient. e.g. If/when South Korea cracks down on the physical servers located @ astalavista.box.sk [astalavista.box.sk], it would resurface in a nebulous new form.

Myth #2: The Net Is Too Interconnected to Control:
TechReview's argument: Gnutella had to implement supernodes in order to fix its old bottleneck problem. What once was completely distributed now has a bit of hierarchy, and hence, is easier to attack with the help of the mega-ISPs.

My counterargument: There's a big difference between a massive central server being targetted, and hundreds of thousands of potential supernodes, which can also pop into and out of existance with the same ease as regular peers. Also, they mention that ISPs may move from simple port blocking to traffic analysis in order to defeat gnutella, and other 'rogue' packets, by sniffing their signature. That will work, but it also means that they'll NEXT have to blacklist ALL encrypted communication too--fat chance of that happening.

Myth #3: The Net Is Too Filled with Hackers to Control
TechReview's argument: You can restrict free communication most effectively at the hardware level. If consumers won't buy the crippled products, it becomes governments' job to mandate it, "just like [they] insist that cars have certain antipollution methods."

My counterargument: I think people will get off their asses and 'revolt' before their last bastion of freedom be co-opted by the system. Also, as long as ANY communication is still possible, you can hide whatever data you want to communicate within that channel... defeating the orwell network.

We'll never be as fast as Akamai... Just because Akamai gets to trust all its nodes. Without that, I'm sure all their algorithms fall to shit. And if they are provably the most efficient, then we can never be as efficient as them.

The below is almost wholly opinion based on vague observations of the universe. You may want to skip over this post, it rambles. I almost either posted it as AC or didn't post it, but i'm osting it using my account so i can get the score so people can see it and respond to it. I don't want moderator points, just responses, preferably from people who think i'm wrong (and can politely justify thinking i'm wrong).

Once again, this is a sign that operating systems that tie you to a given hardware architecture are holding us back, and that apple made a horrible mistake in not porting mac os x to alien hardware.

Those companies that make software platforms need to realize that they **need** to learn to be hardware agnostic. Completely. Tying yourself to a platform is just not safe. Your operating systems need to be designed such that the hardware communication bits and the operating system bits are totally seperated-- as os x/mach is-- and you need to find a way to make the practice of distributing biaries obsolete. We need, badly, some kind of abstract machine code that can be "compiled" to any hardware-specific machine code in an equally optimised fashion. I mean-- you would compile your program not to machine code, but to some kind of rpm-like package in a standard abstract machine code, the user would obtain and double-click this package, and the package would compile itself into the machine code of the computer the user is sitting at. (Since this would require retaining some algorhythm information in the machine code, this would make disassembling / reverse engineering easier, of course, but it would still be highly rpeferable from a corporation's point of view than releasing your source for people to compile would be.) And no, unless your hardware is designed to make JIT interpreters transparent, VMs are not the way to do this.

If they do not find a way to do this? Well, wholly open source operating environments (i.e., systems with no closed source portions, such as debian) will then have an incredible, incredible advantage at some indeterminite point in the future (once there is actually a) actual competition in the processor market between a variety of architecture types, instead of the current "you're imitating x86, you're apple, or you are very high-end" situation and b) a large enough portion of linux/bsd users to sustain actual competition in the processor architecture market). Why? Because once the current ways of doing things start to exhaust Moore's Law, and people start looking for incredibly different ways of doing things, we will start to see a whole class of devices that only really shine under open source software-- because the closed-source world has to ship a different installer for each hardware architecture that the OS runs on, and the open-source world only has to ship one.tar.gz file and it will work on all architectures including future ones. Apple and Microsoft can port their OSes, sure, but what to? Moving an OS to a wholly different architecture is a HUGE undertaking, one i think only apple has done before, when they moved from 680x0 to PPC. Apple did that about as well as anyone could, and it was a tortorous process, in which the PPC macs had to have a built in 68k emulator that the last 10 years worth of software-- and at first, parts of the operating system-- all had to run through. The result was that until OS 8 came and the last bit of 68k asm was purged from the operating system, everything ran at a speed far under the PPC's potential. Emulators are *slow* and not fun, and convincing every app designer to recompile and redistribute their apps and/or release "fat" binaries for every mac app they sell is not easy. Besides which, this is only temporary; you just have to wait long enough, and eventually your architecture will exhaust its limits. Apple can cling to the PPC for a long time, and they can move again if they have to. But even if they do move to a different processor architecture-- which will be stronger? Mac OS XVII, which after much porting work by apple and all mac os vendors runs flawlessly on the Motorola DXM architecture, or ErOS 6, which can run on the Motorola DXM *and* the Intel Ubertanium86 *and* four other completely new architectures with alien instruction sets-- all completely flawlessly because all software is distributed as source code, and the user just compiles everything they install on their own machines, with the compiler optimising things for what the user needs most? Without a way for each user to compile the code, the decision of which architecture to switch to would have to be unanimous for all users of the operating system-- pick one path and stick to it-- instead of letting the individual user choose which architecture has the most cost-for-speed-efficient chips at the moment. There is, of course, the possibility of compiling your entire operating system and all apps into some VM, so that the OS and apps don't know which processor they're running on, but this would be slow too (unless you could have all machines regardless of processor have a coprocessor to do the JIT compiling for your VM in realtime, but that would be clumsy in practice)

(Please note that i don't particularly think that open source software ruling the software industry would be a bad thing at all.)

I don't think microsoft would bother with either bytcode or emualtion, though; they'll just stay where they are, where they're comfortable, and assume that they'll halt change in the processor market rather than change in the processor market halting them. (Meaning once we're all using chips that realign their logic pathway map for each program, and MS is still using something x86-compatible, game companies will start noticing linux and it'll all be over for MS.) Apple, meanwhile, has ALREADY used their Super Kernel Messaging Mach Microkernel Powers to easily create an OS that, thanks to brilliant design, runs equally well on all architectures it is written for and can be ported to a new one in a matter of days ("there are billions of incompatible wintel devices, and you have drivers for none of them" nonwithstanding). And once they had done this, what did they do? Release it for one system and one system only. Had they come up with a way to distribute software in abstract machine code (in the way i clumsily described it above) and announced plans to at some point in the future release os x versions for all architectures in existence, they would now be poised to conquer the world; but they didn't. And they're not.

Either way. Someday, we will reach a point where the operating system must be completely agnostic as regards hardware. This means abstractly designed architectures like Hurd and Mac OS X will have an enourmous, enourmous advantage, and hardware-tied monolithic thingies like Linux will have to flounderingly transition to each new architecture. (PS: which of the above two camps does NT fall into? HAL? What's that?) It also means that debian's decision to let apt-get compile and install source packages for you as transparently as if they had been binaries is the only correct desicion they or anybody else could have made..

1) This is old news. You can find a much better story [eetimes.com] from yesterday over at the EETimes.
2) This is for embedded systems and is not really relevent for PC based systems.
3) This isn't even taped out yet... matter of fact they are not even planning to have the design done for another 18 months... it is vapour until you can actually buy it and that isn't slated until sometime in 2003.
4) This might give Transmeta a serious run for its money if it is ever produced, because they are both in the same space... Of course, TMTA being still around in 2003 is a bit on the presumptious side.
5) Oh never mind, why do I even bother...

Looking at some of the people working for/with this company, I'm not gonna jump on the "it has to be a myth" bandwagon....

Terry Gannon - Independent consultant. Terry founded TeraGen and has held executive positions at Xilinx, Seeq and Sun Microsystems.

John Payne - Chairman of Fast Chip. John is the former president and COO of IDT; president and CEO of Star Semiconductor; president and COO of Rendition.

Rick Shiner - Venture partner with Woodside Fund. Rick is the former president and CEO of Hotrail; president and CEO of Exponential Technology. He has also held executive positions at Apple, Intel, Motorola and Wang Laboratories.

Tom Whiteside - Independent consultant. Tom is the former president of MIPS Technology. He also served as the Vice President of Microprocessor Development at IBM and most recently served on the board of Chicory Systems.

Bill Goins - Marketing Angel. With over 25 years of marketing leadership, Bill founded Powered,Inc. and performed COO, VP or executive marketing roles at Micron Electronics, Power Computing, Apple, Dynamac and NL Information Systems.

There really is some intelligence and talent working for this company, I'd like to see what they can produce. Maybe in a few months, if there's no decent benchmarks (by that time, someone somewhere should have written code to use their logic, right?), then I'll jump on the "it's a myth" bandwagon, but I'm willing to give them a chance first.

... for a while in the late '99-early '00 region as a PFY sysadmin. If they say they can do something, I'd lay good money on them doing it. The level of expertise and knowledge displayed by their staff was stunning. More specifically, I do recall some of the engineers talking excitedly about this stuff at the time and mentioning breaking the 2GHz barrier (keep in mind this was in late '99), so this is hardly a publicity stunt as it's been in the works for quite a while if it's the same thing I was hearing about then...

They were the Austin branch of a company called Exponential Tech. Doing a google on that should bring you up to speed on the Apple connection. I wouldn't really consider them a startup as they've been around for several years and have designed a number of very popular things (e.g. DSPs for other
chip manufacturers).

They were a great bunch to work for, especially for being kind to a rather wet-behind-the-ears sysadmin like I was. The only downside to working there was the gawd-awful commute I had to do from far NE Austin to far SW Austin. (If you're an EE type who'd like to live in Austin, they'd IMHO be a great place to work [intrinsity.com]for)

yeah, from what I read it was intended to be a third party accelerator for ppc systems, like in the 500+ MHz range at a time when most ppc chips were in the 200 MHz area. (somewhere in the 95-97 time frame as I dimly recall) Apple decided to purge the heretics around this time (c.f. Be and PowerComputing), and denied third parties access to things like firmware specs... when I was curious two years ago I googled up a number of articles about the whole thing.

I remember the 533MHz model drawing well north of 80W of power -- which when compared to the PPC750 is almost an order of magnitude more, clock for clock.

Apple has shipped at least five million units since those times; imagine if all of them would draw,say, 50W more than they do now? At three hours use per day, that'd be, what, more than 600GWh wasted every year...

Rather than license its technologies to semiconductor vendors that would wind up as competitors in the marketplace, Nixon said Intrinsity will focus on getting its initial processor design finished over the next 18 months. Going from the test chip to a full-blown embedded processor will consume the energies of the small company.

1) This is just a prototype.

2) They seem aimed at the embedded market. I don't think that you will likely see "meaninful" benchmarks.

They also benchmark with Media Cleaner Pro, which is a very widely-used media encoding application. At this past Macworld Expo NY, a Mac with a G4/867 in it took a Spiderman movie trailer from tape to Web, and then played the result, well before the similar Intel machine (1.7GHz P4) could even finish encoding the clip. Same task, same media, same application, same RAM, same hard disk, same graphics adapter. Only thing that's different is Mac OS / Windows, G4 / P4 and the mobo. The machines even end up being equivalently-priced (I think they use Compaq workstations for these tests).

> How could anyone question the validity of an

> application that has always been primarily a mac
> application?

Photoshop has been running on both Mac and Windows platforms for years and years now. It is optimized for Intel with the assistance of Intel engineers. It is optimized for the Mac by Adobe engineers all on their own.

I work in music and audio, and it is very performance intensive... all of your processing is done in realtime. The Mac runs music and audio apps faster, too. I get incredible performance in Cubase 5.0 on a PowerMac G4/733. You can fill up all of Cubase's plug-in slots and still have CPU power left over (there's a CPU meter built-into Cubase... that's how CPU intensive it is). Latency is also better on the Mac, and that's very important in audio.

Video, music and audio, graphics, encoding and encryption... the Mac is the best-performing machine for all of these. These are the tasks that Macs are BUILT FOR. It just so happens that everybody wants to do these things now, thanks to digital camcorders, cameras, MP3's and security. Doesn't magically make Intel machines any better than they are, no matter what the clock speed of the CPU.

Latency is also better on the Mac, and that's very important in audio.

Video, music and audio, graphics, encoding and encryption... the Mac is the best-performing machine for all of these. These are the tasks that Macs are BUILT FOR.

And if Apple really wanted to let you tap into that power, they would have shared their hardware specs with Be.

The primary reason Be ported to x86 was because Apple got pissed at them for showing up MacOS on the PPC architecture. Apple took its ball, and went home.

So if you really want a fair comparison of architectures, why not compare BeOS on x86 to MacOS on PPC? I realize it's not likely, the same types of apps are not available for BeOS and probably will never be... but let's not chalk up these so-called benchmarks to the CPU architecture quite yet...

That said, Be didn't stop porting because they needed the specs. They didn't need the specs. They stopped porting because they wanted to stop. Perhaps because they wanted to know that Apple would support them in the future, but whatever.

Be created BeOS for their own hardware, using Hobbit processors. (The BeBox.)

These did not sell well.

They scrapped the idea of selling hardware and ported BeOS to PPC. BeOS began to win acclaim as it smoked, esp. compared to MacOS on the SAME EXACT HARDWARE.

G3 came out and Be could not get Apple to release the specs for G3 hardware that prevented BeOS from running on the hardware.

Be ported to the more open architecture of x86, for better or worse, and their user base grew beyond what they achieved as PPC-only.

I think it's pretty clear Be was no longer competing on hardware. Apple did not share the specs because they were tired of getting shown up on their own hardware.

That said, Be didn't stop porting because they needed the specs. They didn't need the specs. They stopped porting because they wanted to stop. Perhaps because they wanted to know that Apple would support them in the future, but whatever.

When I said "And Apple stopped sharing specs because they didn't want harware competition" I didn't mean that Be was the one providing that hardware competition. They stopped sharing their specs with *everybody* because they didn't want any hardware competition. Be was sortof a civilian casualty.

And, BeOS smoked on the exact same hardware... at *what*?

Of course it smoked at multitasking, and most everything that any user cares about. I'm not about to suggest that it wasn't more efficient than MacOS in the general case. But this was a discussion (long ago) of photoshop/media cleaner performance. That sort of app does not benefit from multitasking or any of the modern features of BeOS. They benefit from the ability to monopolize the processor. The only reason that I responded to your original post is that it is not likely that photoshop's performance would be improved hugely by BeOS.

I hate to add to an obviously silly conversation, but you state that Be could not run BeOS on the new G3 Macs because Apple would not release the specs for the new hardware.

Good theory. And it is what Be said.

Do you know how long it took for the PPC Linux developers to get the Linux kernel running on the new G3 machine? About 2 weeks. How many people work on the PPC specific parts of the Linux kernel? About 2 or 3. I can only guess how many software engineers worked at Be at the time, but I imagine more than 2 or 3. So, how stupid do you think people are? Be didn't get BeOS running on the G3 because -THEY DIDN'T WANT TO- just as Elwood said in a parent post to this. The fact that they lied and whined that it was Apple's fault made me lose a great deal of respect for them.

I'd also like to point out that Apple is a HARDWARE VENDER. Do you think Apple makes money selling MacOS X for err, $89 or so? Of course not. It's a loss-leader to get people to buy their hardware which has a higher markup than most consumer PC hardware. People have been talking for years about how Apple should give up on hardware and moving to software. It won't happen. Apple losing control over their hardware platform would greatly reduce the added value that their products give over consumer PCs.

Apple is not the only company talking about the "Megahertz Myth". Intel uses it to sell it's Xeon chips to businesses at much lower clock rates and higher prices than the P4; Intel uses it to explain why Itanium runs at 800MHz; AMD's new chip runs at 1.5GHz, but they say it outperforms a 2GHz P4; Alphas run at 1GHz but are acknowledged to be much faster than a P4; Sparcs run at 900MHz, yet are also acknowledged to be better performers than a P4. There is also a precedent from the old Intel/AMD/Cyrix Pentium days, when the "P-rating" was born because the top-MHz chips were not the top performers. With the whole industry using the same process, and the P4 standing head-and-shoulders above everyone else in both MHz and pipelines, it's not hard to imagine that it's an underperformer. You don't have to ask Apple about that.

Apple does real world demonstrations of Photoshop and Media Cleaner Pro. If you are working with images at all (in graphics, video, Web browsing even), then the calculations (such as resizing or blurring an image) that Photoshop is doing faster on the Mac are germaine (Photoshop's filters are even used in other graphics apps). If you are doing any kind of encoding or encryption, then the Media Cleaner Pro demos are germaine (the Mac took a clip from tape to Web, then played the clip for the audience, and the Intel machine still wasn't done encoding yet). The files for the Media Cleaner Pro demos are just whatever movie trailer is newest (last time was Spiderman). Apple also demonstrated realtime, high-quality MPEG-2 encoding on their fastest PowerMac at the last Macworld. There is no counterpart on a Pentium for them to benchmark against. These are the things Apple's customers do with Macs, which are built to run these kinds of apps. Apple just demonstrates that their machine is better for those users. What, exactly, makes you think you know better?

TechTV was also skeptical, and they recreated an Apple demo, pitting a G4/733 against a P4/1.8GHz and the Mac won. TechTV is not a Mac-friendly site, and indeed they had openly disparaged Apple's test before they did their own version. They called it a draw, but add up the numbers and you'll see that the G4 finished the overall set of tasks faster.

The reason they use the word "myth" is that it is a falsehood that people WANT TO BELIEVE. It would be great if the 1.8GHz P4 was really twice as fast as a 900MHz PIII, but it is not. At the same time, it's easy to point at the lower clock-speed of the G4 and get in some good Mac-bashing. Unfortunately, it just shows that you're an idiot who hasn't used both platforms. If you had, you'd hold your tongue. I mean, if P4-based machine were doing these huge CPU-intensive tasks twice as fast as Macs, then why are people still buying Macs? Photoshop and Media Cleaner Pro are mature apps with the same features on both platforms. In these fields, time is money, and what hardware you buy is almost irrelevant. The cost of switching is nothing if you get to go twice as fast once you get there, yet people who have to encode hours of video everyday are not trading in their Macs for P4's. Two of the three PowerMac models come with DVD burners and MPEG-2 encoding software built-in, and people are making high-quality DVD's at home now, in 2x or real-time. That's very heavy computational lifting.

Intel uses it to sell it's Xeon chips to businesses at much lower clock rates and higher prices than the P4; Intel uses it to explain why Itanium runs at 800MHz; AMD's new chip runs at 1.5GHz, but they say it outperforms a 2GHz P4; Alphas run at 1GHz but are acknowledged to be much faster than a P4; Sparcs run at 900MHz, yet are also acknowledged to be better performers than a P4.

There seems to be some confusion. SPARC, Athlon, Alpha, and Itanium are not faster performers than P4 (except the Itanium which beats P4 at FP).

A friend of mine recommended going to a 4.10 gear, but I think it would be too low - Im thinking maybe a 4.30 gear would be better. Narrowing or tubbing is not an option, and we've fitted the biggest tires possible. What is your opinion?

First off, it must be a lot of fun when you get a silly little Honda pull up beside you and think it's gonna race you - or is it strip only? (Ignoring slicks, because I've driven on the street with them, that setup is a little wild for Saturday night cruising!)

Okay. Let's do the math. TH-400, as far as I know, is a 1:1 ratio in top gear. If your rev limiter is kicking in at 7,000 RPM, and your torque converter stalls at 4,800 RPM, there's something wrong if your driveshaft isn't spinning at the same speed as the engine.

I'm coming up with 1,535 RPM. That's the speed at which your rear wheels will be spinning.

Now, once you know the circumference of your tires (you gave me the width, which is good for establishing that you're getting traction), you can calculate your speed. Remember also that your tires will be pulled larger by centrifugal force at high speeds, this will affect your calculations.

Compare this speed with the terminal velocity on your timeslips.

Experiment with the differential numbers and recalculate the speeds (fire up the spreadsheet in StarOffice) until you come up with a number bigger than the terminal velocity on your timeslip. I wouldn't go much higher than whatever rear gear gives you a small rise over your current terminal speed, going too far will eat your 60-foot times - but so will a bad day at the strip, you should be more concerned with wasting power on the rev limiter.

Since they're likely to be the tallest tires you can fit into the factory wheel wells, I'd take a guess that 4.30 gears will put you into range. Consider, though, where your engine's horsepower curve starts to come down - probably before the rev limiter kicks in. Maybe 4.10, but just by gut, I still think that 4.30 would be better.

Yep, here it goes again. Everybody needs a PCI bus that allows the sound card to transfer at 8 GB/sec, and a system bus that can keep up with the soundcard... Get real. Bus speed matters, but so does CPU speed. Either one is a welcome advancement.