Slashdot Mirror
Speculations Intel's Next Generation
An anonymous reader writes "The Inquirer speculates about the next generation Intel chip. It's low power, 64 bit, multi core (up to 16?) and the real reason for the Apple switch."
← Back to Stories (view on slashdot.org)
To me that sounds a lot like Sun's Niagara box. Huge CMT box (8 cores, 4 threads each, 32 way box). With power consumption around 65watts, but faster than 4way Xeon processors and probably more like an 8way depending on application. Intel probably is moving to something similar, maybe not quite that many cores and threads.
It can just continue selling the high performance Hammer, it already is 64 bit, it has more than 1 core (I am sure they can add more), and I am also sure they can make it low power eventually, in other words nothing to worry about.
This article was written by Nicholas Blachford, the same fool who tried to analyze the Cell processor of the PS3 and described it as a supercomputer on a desk while not understanding a single thing about it.
Seriously, it's worth a read for the laugh, but there's nothing worth believing in it, this guy doesn't know what he's talking about.
AGP, by it's design, can only have one per machine.
It was an add-on specifically designed for the pattern of usage that video cards perform - lots of data out, and short requests in.
It was a patch to get us by until the "next PCI" came along - but AGP's great performance was also the reason it's taken so long to get PCI Express going; not a lot of demand for something we don't really need. Old PCI slots still provide ample bandwidth for most other types of expansion cards and on the server side you had 64-bit PCI/PCI-X.
Of course, we still needed PCIe, but it hasn't been a big push. Now, with the dual-video board thing happening, it's definitely helped push the bus into the mainstream.
As far as the changes in CPU slots, well, I agree to a point. While I believe that both Intel and AMD could have done more to keep slot changes to a minimum, a lot of times the chip-set changes along with the CPU requiring a new board anyways. So, why not upgrade the CPU slot to accommodate the new data patterns of the new architecture?
I do feel like I own hardware. Software, on the other hand..
- It's not the Macs I hate. It's Digg users. -
All the rumors I have heard seem to suggest that the high-end desktop hardware (PowerMac, XServe, high-end iMac configs) will be the last to switch to Intel.
If Apple uses Pentium M and its successors to solve its laptop/Mac Mini problem, it can probably afford to wait on the high-end hardware. IBM has already announced dual-core G5s which should be good for another PowerMac revision or two.
By that time, if there is a mythical Intel 64-bit magic chip, it will be on or close to market.
Wrong.
Miss-behaving applications could bog down other applications because Mac OS used "cooperating" multi-tasking. An application, through it's normal course of operation, would relinquish CPU time through it's event loop(s).
It's a transparent process done simply by polling the system for your next user, system or idle event (aka, "WaitNextEvent()"). This is where Mac OS' multi-tasking defers from preemption modern OSes offer (Linux, Unices including OS X and Windows). In those OSes, the kernel is the one that decides when to switch out the CPU's attention.
Any application not relinquishing CPU time when it didn't need it was immediately considered poorly-programmed and seldomly used.
A developer's poor aptitude was no excuse for the Mac OS locking up. It offered everything you needed to make things to smoothly. It just required a bit more thinking.
Dont get me wrong. I prefer OS X to what we had back then (I've been developing, professionally, Mac applications since 1988 so I know what we had back "then"). But It's important not to skew the facts.
Tell us in what way Mac OS {10-n } was a) buggy b) unstable and c) single-threaded?
(a) is a matter of opinion. (b) isn't; an OS where a single application failure can easily bring down the whole system is unstable by definition. (c) is technically false, but effectively true. The Thread Manager only supported cooperative threads, which doesn't really count. You could create preemptive threads with the multiprocessing API, but they were very limited as to what they could do (no memory allocation IIRC).
I'm a Mac fan too, but there's no denying that the internals of Mac OS pre-X sucked. I still preferred it to Windows because of the UI, but I'm very pleased that with OS X I no longer have to make that tradeoff.
How to solve most of our problems: 1.Lots of nuclear plants. 2.Cure aging.
Yea, not really. Dual AGP requires some hacking and it's not standard. It *can* be done, but it wasn't designed to be, and therefore requires special working to make it happen. It never became mainstream because it doesn't work very well.
- It's not the Macs I hate. It's Digg users. -
While I agree Apple's processor choices have not been the best, they are also tend to try to use all the features of the hardware they are running on (altivec, GPU) - certainly in part because of the fact that they don't have the best processor around. This might be why Intel is so keen for Apple, instead of having to beg Microsoft to use their new features, they now have another OS builder with a stronger incentive to use them.
If you put your tinfoil hat on - heck if we start purely speculative articles - you might argue that one of the goal of intel might also be to stop the trend of running things on the GPU (well as long as they are not intel GPUs). If the whole "let's run the windowing system on the GPU" idea would have reached the mainstream sooner or later, Apple probably did push things forward.
While I agree that one of Itanium's problems was that compilers were not good enough, there was also the whole issue of nobody actually really using the thing and optimizing for it. The server market it was aimed at was not a very good choice, the server market is very conservative and this is not a context where optimizing a few critical libraries makes a difference. The reason Apple could pull out the 68K emulation is that the CPU spent 70% of the time in the GUI libraries.
why migrate their developers over to writing x86 code as an interum step, instead of waiting until after the VLIW architecture is available, and migrate directly to that?
VLIW is basically to move a lot of the 'smarts' like instruction reordering and branch prediction from the CPU to the compiler. Thus freeing up a lot of transistors that can be used for cache or additional ALUs.
The compiler has to be very good, though. And you also run into problems like having to recompile when the next generation of the CPU adds more ALUs or has pipeline changes that requires different instruction ordering. So VLIW is not at all a nice type of architecture if you want binary compatibility between several generations of the CPU. Which is why the article mentioned Transmeta - which had a software layer that translated between x86 and the native VLIW languages used on the different Transmeta CPUs.
If the article is correct, the next generation Intel core will be VLIW internally, but will execute IA-32/EMT-64 through a software layer like Transmeta.
If J.K.R wrote Windows: Puteulanus fenestra mortalis!
Mac OS up to OS 9 was a Co-operative multitasking OS....OS X is fully preemptive