In the Comments to yesterday's article the concept of having 80486DX cores (instead of 80386 cores) was brought up. In moving from the 275K 80386 to the 1,200K 80486DX we would definitely lose some of the 1,400 potential cores we had in our theoretical die; I decided we would drop down to an even 128 cores and leave it at that. A regular ChipGeek reader named GoatGuy also postulated that the maximum theoretical speed of the 45 nm 80386 would not be around 133MHz as I had predicted, but would be closer to 225MHz.
That being the case on a three-stage pipeline on the 80386, we can assume that the 5-stage pipeline of a 486DX would allow for even greater clock speeds. The final 486DX/4 processors were clocking at 100MHz, so let's assume we could easily get them up to 333MHz, possibly even 400MHz to 450MHz (something just about Pentium II speeds).
So, if we have 128 486DX cores operating on a single die, each with its own internal 8 KB of cache, we can begin to put into place some realistic expectations for performance. The 486 core has an in-order execution engine, which means that it can only do one thing at a time and exactly in the order specified. Note that it wasn't until the Pentium Pro that the out of order, super-scalar, super-pipelined models that are still in use today came into play. They were capable of doing two things at once, and could reorder instructions and colorize register use so that instructions that could not normally be executed in parallel (because they used the same register) could now be executed in parallel. Those were the big changes seen later that really allowed performance to increase.
Since we've got an in-order processor we can determine some realistic demands on memory. Operating on an average three-byte instruction opcode at a rate of 333MHz would require a maximum of 1,000 MB/s of memory bandwidth just for the instruction stream. Since we know that x86 code is inherently loopy and branchy, the majority of that would be serviced by its own cache. So, we drop that down to a more realistic 100 MB/s of memory bandwidth, add on another 100 MB/s for data, and we find a need for 200 MB/s per core. Multiply that by 128 and we're siting at 25.6 GB/s maximum throughput to service memory requests.
If we divided the memory subsystem up into 8 separate units, each serving 16 cores, the taxing need of NUMA-aware software becomes significantly less burdensome on hardware. The 8 memory units could coordinate memory ranges that are outside of their own physical range, allowing for inter-unit communication and coordination (just like the way HyperTransport tunnels work today). The 25.6 GB/s suddenly becomes 3.2 GB/s. If we realize a FSB speed of four times actual clock speed of the cores, we find our 1,333MHz FSB would only need to be able to serve up 2.4 bytes per cycle to fully saturate the block of 16 cores' needs.
That's wholly doable!
I must ask the very serious question now: Why aren't we seeing this being done? The profit potential from a tried and true 486DX core–one that's already been tested, debugged, validated, and so on–simply migrated to modern day business-line tools for the production of modern microprocessors, especially one that only contains 1.2 million transistors … well, it just seems like child's play, and one with the potential to make a company so much more money. After all, we're talking about the number of dies per wafer and how much they could be sold for.
If this particular chip were actually created it would undoubtedly have several orders of magnitude more performance than today's highest-end dual- or quad-core processors! The only downside would be that, while it had that much computing prowess, it would only be truly useful for tasks that can operate in parallel. Still, with the modern operating systems of today scheduling literally thousands of separate threads during normal program execution, the ability for 128 cores to tackle those thousands of threads would still provide significantly more throughput than one or two cores servicing them.
I can see so much potential here. I wish I had money because I would be designing this beastie right now. I would be running development simulation software all day long, ones that emulate real 486DX core logic units, replete with execution cycles, clock cyles, cache access, memory access, etc. To me it seems to be a very easy project to engage in on the theoretical side. Now, taking that theory and putting it to silicon is something true engineers would have to do. But sitting down and working through the math (in theory) is something I think any reasonably intelligent software developer could do.
So, Geeks … what do you think? Should the Geek CPU project be migrated to the grain-of-sand idea, one where we either have a single 486DX core shrunk down to 45 nm processes, or we have a host of 486DX cores on a single die all working together?
And before I leave you, let's consider the original 8086 and 80286 processors. Shrunk down to the 45 nm node we could get roughly 13,000 and 3,000 cores respectively. With the increases in clock speed potentially available, the throughput on those machines would be phenomenal.
USER COMMENTS 13 comment(s)
|Guessing there's a good reason… (8:57am EST Thu Mar 08 2007)
Might be going out on a limb here but I'd have to guess there is a good reason this isn't being done. If you accept that INTEL has their 80-core idea then you have to assume that somewhere in that meeting someone put this on the table. It only makes sense.
Not sure if the reason not to do it came from the finance guys, the engineers or the marketing guys but someone had a good reason not to follow through.
You work it out… – by NoOne_Specific
|GPU (11:43am EST Thu Mar 08 2007)
Outside niche markets (server farms, specialized computations, etc.) the only mass market application I can imagine right now is a GPU.
Although a lot of the “general functionnalities” of the 80486 wouldn't be used at all, rendering space can be divided into parallel rendering areas, as we can do with an SLI setup for instance. However, the way today's GPUs are driven by DirectX and OpenGL (still talking mass market here), it seems better, speed-wise, to partition data in the 3D space rather than in the 2D rendered space (that's however merely my impression and I have yet to find facts to support that claim.)
The processor array would nevertheless really benefit other rendering processes such as raytracing, where parallelism is obvious (let's say each processor renders a 32×32 pixels area). For instance, folks at OpenRT () are getting better and better at real-time raytracing (such as running games), and with that 128 x 486 processor pack, that could surely help that projet, and raytracing in general, become mainstream.
|limits to number of cores (12:43pm EST Thu Mar 08 2007)
It seems to me that there are a couple of problems with CPUs with a large number of cores:
1) The art (hardly a science) of writing computer programs is so poor that we have to design the hardware around the limitations of programmers rather than designing programs around efficient hardware architecture.
2) The chip would have to be designed like a telephone exchange to switch data between the cores and the proportion of the chip required for this would grow rapidly with the number of cores. – by mjb
|13,000 (1:32pm EST Thu Mar 08 2007)
8086 cores would be very useful in neural network applications. Each core could would essentially be used as a simple processing unit in a massive network. – by bookgoldminecom
|Software Problem (1:38pm EST Thu Mar 08 2007)
Everyone keeps talking about there being a software problem. But there isn't really. Writing a program is not a mystical thing. It is hard and fast and it follows explicit steps. I know this because I am a low-level software developer who routinely works in assembly developing operating system level code.
The actual mechanisms employed by operating systems to execute multiple programs would be far, far better served by having dozens or hundreds of cores. For the OS it would simply schedule a particular thread on a given core and it would go. The more cores you have, the more threads run simultaneously.
Since a single core would be given a single thread, and would not have to time-share its processing power with many other threads, the throughput would be relatively high–even though the processor itself is physically slower (due to clock speed and limitations on cache/memory).
The extra wait time here and there would be commensurate to that thread sitting completely idle while the OS services the other 1,000 threads each second.
People are making a much bigger deal out of software limitations on multi-core processors than they need to.
Will individual applications that aren't multi-threaded run faster on a multi-core processor? Probably slightly because the actual work related to drawing video, reading hard drives, etc., can be handled in other threads, but not significantly otherwise.
But, will 500 programs running simultaneously run faster on a 500+ processor core? Absolutely because each of them will appear to be the only program running on its “machine”.
The individual applications might run more slowly, but on the whole there will be a lot more being done and the machine slowdown (even dropping down to 133 MHz 80386–which would be about on par in performance with a 133 MHz Pentium, by the way) will not be nearly as noticeable as people think.
Multi-tasking robs a PC of its true performance. When a single task can run on a faster core, that's great. But on the whole, if you do more than one thing, having dozens or hundreds of cores would be better.
Not every user would see consistent benefit there, but I bet that all users would see real benefit there at least during peak usage with their systems.
Also, consider the advantage for gamers.
|Subtract Control Logic!!! (1:39pm EST Thu Mar 08 2007)
Don't forget that even back in the day of the 486, there was still a significant amount of control logic built into the core to handle context switches and dynamic execution.
I think this would be outside the range of your pet project, but if you consider stripping down each 486 core to only handle one thread with no on-core switching… you'd be able to half the number of transistors a-la-CELL processor's SPE's.
One large control unit could dish out threads like a poker-dealer to all these dedicated, tiny, efficient cores.
|Rick (2:06pm EST Thu Mar 08 2007)
It's called Fine or Coarse grained parallelism. when you need to wait on a result, to go to the next result, it doesnt matter if you have a billion cores. There is simply a limit as to how much can be done in parallel, not that we are pushing this yet. – by Doh
|Doh (3:55pm EST Thu Mar 08 2007)
My point is that it doesn't matter. You don't need to have parallelism coded for in order for applications to still work. They'll just be slower on a chip like this. But, if you were to use a chip like this you wouldn't be going for high-speed single-app abilities anyway (those that can't be executed in parallel), you would be going for the high-end throughput available for multi-threaded apps.
Which brings me to another thought. How about having one of these cores as a drop-in compatible replacement for existing AMD or Intel sockets? You'd have a single dual- or quad-core processor in one socket, and this kind or processor in the second socket (and 3rd, and 4th and so on).
– by RickGeek
|Rick (7:18pm EST Thu Mar 08 2007)
True, but there is still a lot of software that does depend on calculations being completed, or waiting for user input. How about combining a few high speed cores for those threads, or better yet running them on a high speed processor while letting the rest of everything be handled by the 486s. I'd go 486 just because they were cooler…And every 486 I know of, flat out stomped on any 386 unless your counting 486 slc by IBM. Then you had to max the cach and do an 80437 co processor. – by Doh
|Doh (7:39pm EST Thu Mar 08 2007)
The 486DX had a built-in FPU. The 486SX used an 80387 FPU.
I don't have a problem with high-speed cores. For single-threaded apps, or those driven by mutexes, they are required… but the type of computing I'm talking about is different. People wouldn't be going for raw, blazing speed on a single thing. They'd be going for functional and usable on most software, and then absolutely blazing on the apps that can be processed in parallel.
Consider video or audio processing. 1,400 386 cores working even at 1 fps processing speed would be able to process 1,400 fps, or about 47 seconds of video every second. A 2-hour DVD could be converted using that kind of core in 144 seconds. How long does it take those high-speed cores to convert a 2 hour DVD to MP4 today?
And what about audio? And what about gaming? Maybe every core could only do 1/4 fps using modern 3D engines, but 1,400 CPUs at 1/4 fps each equates to 350 fps, and that's with everything offloaded to the CPU and no GPU doing any processing.
Also FWIW, I'm not trying to dictate here. I think your idea of having a high-speed core is a good one. In fact, I wouldn't mind having simply a couple hundred of these 80386 cores tagged on to the outter-edges of a modern day dual- or quad-core processor. There are many things which could take advantage of that many relatively high-performing cores (compared to the original 80386).
Also, FWIW, if you go to one of the old computer shops and find an original 80386 running DOS 6.x and Windows 3.11 for Workgroups, you'll find that it's not horribly slow. Imagine taking that 33MHz machine and making it 4x faster.
Oh well… I'm sure there's a reason why they don't do it. To me, it just makes sense to take the older processes and migrate them forward. Especially with a core as simple as the 80386. I'd be most modern-day grad students working with a team of 10 or 20 guys could work out the bugs on a processor using only 275K transistors.
|Nice supercomputer on a chip (8:36pm EST Thu Mar 08 2007)
I think the speed advantage you envision Rick is that instead of wasting performance on context switching thousands of times to handle all of the operating system threads, the os could instead dispatch one process per cpu core. I think this would be awesome for certain workloads, but the way people use their cpus today, they rarely reach 100 percent utilization except under specific conditions like multimedia encoding or games. Maybe someday this won't be the case, and every computer will need to be running thousands of intensive processes, but today it's not happening. It is quite common in dual core systems to have one thread using 100 percent utilization on one core and the other sitting idle, easily managing and taking care of all the background jobs. This would indicate to me that managing things like process scheduling is really not that intensive for today's processors.
Of course, your mileage will vary depending on the kinds of tasks you do. Applications like video encoding which are easily parallelized will make the most use of this and others like games, will see improvements up to a certain point. A design like this would be good for servers that take thousands of accesses and process them, but PC's have no use for this yet. – by futureCE
The software bit always was stuck in the back of my mined. As i see it my computer barely gets pushed to the max which is interesting as we are coming out with faster and faster chips. When will software actualy take advantage of this power were making? I don't even see 2 cores being maxed out and then i think 4 or 8 even … 80 vores, what the heck would need that? I see videogames, maybe movies ad photos, but once you get past 2 bores it's alot of power. Video games that max out a 100 core computer is mined boggling, as to what that would be? Hmmm The Future! I like thinking about it though. – by johnnywalkin