(Disclaimer: microelectronics knowledge level = n00b)
Okay, so upscaling the current designs is off, and adding more cores (a la Samsung?) is also not a possibility.
From what (little) I've seen the Russians are pretty darn good at making robust interconnects. So why not produce a book style processor - with 4 quad core ARM's close coupled - giving you a 16way. You'd need pretty good OS support for such an arrangement, but then again there's that "Russian Linux OS". Plus the Russian's are also pretty good at parallel supercomputing, so basically your desktop would be a vastly scaled down version of one of those processing using.
Blue sky thinking time (hate that cliché), maybe there's even a (remote) possibility of some kind of upgradable arrangement. Start with a single quad core processor element, then add additional PE's as needed. I remember seeing some discussion document from IBM about ways to efficiently connect many processor elements.
Haven't we been saying for years that x86 was "old hat", maybe this'd be a way to move onto something a bit more modern. I'm probably (I'd say "definitely" but I'm being kind to myself) way off base, and am missing umpteen different practical objections, but a guy can dream.
I concur with the earlier message. I remember when DEC could emulate x86 faster than the real thing. Thankfully with a bit of a kick in the butt from AMD 64 x86 got added onto and improved considerably.
However the biggest plus with x86 (legacy/compatibility) is also its biggest hindrance. Given the opportunity to design a new modern processor, I doubt anyone would create an x86 design, not even Intel.
The P4 wasn't a scale up of anything, it was a new design. They made the pipelines very deep to get the clock speeds up, they dropped the cache sizes on the assumption that hyperthreading would make up the difference, they double clocked the integer units to get around the poor thread scheduling, they pretty much made SSE mandatory for floating point but the SSE unit bypassed the caches making it only useful for things like video encoding benchmarks and not scientific workloads. I'm sure every part of that made sense to someone, but as a whole it was pretty bonkers and they took their eye off the thermals so it could never hit the 5GHz they promised.
Now Haswell on the other hand, that is a scale up of the Pentium M, which was a power reduction of the Pentium 3, which was a cost reduction of the Pentium Pro. Evolution works well, scaling and tweaking an existing design. Though it helps to have a starting point like the Pentium Pro, it got slated when it came out but with hindsight that was a superb foundation to build on.
So, can you scale up an ARM? Course you can. In fact, I suspect Apple already have. Their current phone/tablet chip is a bit beefy for its current use. I heavily suspect they are working on a laptop ARM chip.
Then there is AMD. They currently have 2 CPU lines, the big core Bulldozer derivatives and the low power cat series, currently Jaguar. People talk about them as if they are completely independent, but it seems that already if one team come up with a good unit then the other team will paste it into their design. Now AMD are supposed to be coming out with an A57 based cpu, which gets them out of the gate quickly, but it also seems that they are working on a custom design. That gets interesting if they can pick and choose bits of the x86 back end, and feed improvements back into the x86 designs. That could scale an ARM chip very fast.
How much do you have to scale? Not much it turns out. The A9 can do 3GHz http://hexus.net/tech/news/cpu/38817...fortably-3ghz/, so you need a bit more speed and better instructions per clock and A57 already provides a boost to both of those along with the much needed (for server/desktop) 64 bit support.
ARM cores are small, Intel cores are large.
http://static.gamespot.com/uploads/s...1063-23521.jpg
There are plenty of 8 core tablets and phones out there already, by GPU standards 20 ARM cores would be pretty small.
Xlucine (24-06-2014)
Not sure you are remembering correctly, or I guess it depends which ARM chip.
The first one I remember being faster than the x86 was the StrongARM, I recall having a 233Mhz version in '96, despite being fast, a same speed clocked Pentium Pro was faster for most things. The SA would beat it at most integer operations however, but then loose due to lack of cache and awful floating point performance. However the RISC PC had a 16mhz FSB, which just totally chocked operations. RISC OS itself was so damned fast however, it didn't really show, compared to Win95 or OS9, it was just a damned fine no security model OS.
As such certain things it did better, if you had a vector editing program, draw works and the like used vector matrix operations that were completely integer, resulting in very fast performance, compared with the intel crowd using floating point.
But I wouldn't ever say it wiped the floor with the x86 chips, not unless you include power consumption.
throw new ArgumentException (String, String, Exception)
I am thinking of the early Acorn Archimedes stuff. Seemed a nice box, but completely lacking any real software support. I used to joke that it could run its entire software catalogue in just a few seconds
Still, it was up against the Amiga, Atari ST and if you had more money than sense a 386 (more likely a 286). Of course the 386 would tend to run 286 software as dos extenders weren't common and Windows (or DR GEM if you wanted something usable) were 16 bit.
An Archimedes running Zarch was jaw dropping. The Atari could just about manage a parallax scroller, the PC was so held back by huge memory model pointer arithmetic it was barely capable of running stuff like Word Perfect let alone anything vaguely real time. And yes, co-operatively scheduled code with zero security or memory protection was the norm unless you were lucky enough to have a Sun workstation.
The 386 I had was passively cooled and not even sure it had a heatsink, so I don't know if there was anything in the power consumption.
Last edited by DanceswithUnix; 24-06-2014 at 12:26 PM. Reason: Spelling
Yes, I don't think a lot of people realise just how awful x86 was back in the 80s. If someone said in the early 80s that Intel would become totally dominant and outsell and outperform all RISC based design you wouldn't have believed them.
Intel's design had absolutely no forward thinking. If only IBM had selected the Motorola 68K (32-bit data and address registers (even if only 24 bit was mapped which only caught out Apple and their crazy idea of doing something with those 8 bits) back in 1979 when Intel had this chip which was barely 16-bit), decades of PC users and developers having to struggle with crazy 64K memory segmentation would have been avoided.
I think Intel's first decent design was the 486. But having the IBM PC design win made them so rich that they could afford the best fabs, poach the best designers and optimise x86 like crazy. Guess we will never know much less effort it would have been to get something like the 68K to a similar performance but x86 still imposes an overhead. A pity that AMD didn't add more registers to the a64 design.
And now Intel with their x86 everywhere want to go after the HPC market with Knight's Landing. Guess they will eventually get that market too even if Larrabee was a failure. Just looking at the Wiki on Intel MIC it seems the design is x86/x64; would have though ditching the 32 bit stuff would have made more sense.
I used to have to write for Z80, 80(2)86 and 68000. The x86 stuff always took 3 times longer to write and I dreaded having to dip into assembler despite first learning on a Z80 which should have been a firm grounding.
Intel were lucky with the design. The 68K used to update the flags register on almost every instruction which was great as an assembler programmer but made flags a bottleneck when trying to execute 2 instructions at once. Then there were the stupidly CISC instructions they introduced with the 68020 which just about killed it off long term. Motorola apparently undid a lot of the overly CISCy damage in the Coldfire cut down 68K cpu, but I never got to play with one of those. So with hindsite, while 68K would have been nicer as a programmer the performance wouldn't be any better now.
IBM had the basis of decent computing a long time ago: http://en.wikipedia.org/wiki/IBM_801, but at the time the left hand never seemed to know what the right hand was doing so that was never going to get joined up into a proper computer.
What really staggers me looking back is how well MIPS has aged.
Ah ARM when it was still Acorn RISC Machines.
I was more thinking that the StrongARM which even the 233mhz version was still passively coolled, would wipe the floor with the PII when looking at performance per W.
To me the StrongARM was the last great 'desktop grade' chip they did. A lot of the ones before had nice features, but nothing like protected mode of 386. Hating of 16bit (WHY!) memory model aside, that was a big game changer.
It's funny how I was thinking for a project I was on last year, I'd have loved to have had a big StrongARM with many registers and a very fast connection to a bunch of double precision vector processors.
The thing is now we've become so used to high-level software, even getting people to use the strangely familiar CUDA isn't easy, I've known companies pull the plug on projects based on it, because of a 50% increase in dev cost vs x86, kind of silly when you consider their hardware bill savings, but there you go.
throw new ArgumentException (String, String, Exception)
The bit I find ironic is that when RISC first started becoming popular, it was often quoted that the move away from assembler to 'C' enabled the cpu to run RISC code that was unreadable by humans because the compiler would deal with it. Now compilers are good enough that I find myself programming 386/amd64 systems quite happily, when in the past I would find myself having to dip into assembler which on x86 always resulted in language I wouldn't utter in front of the children and rage quit from the editor I never found RISC code making me that angry. Even Transputer assembler never got me that cross, and that was weird.
I remember StrongARM coming out, that was very funny, sort of DEC saying "look guys, you do it like this". Was also the first indication that something wasn't ageing well in the ARM opcode set, as it seems one of the major performance boosts they got was from removing the barrel shifter from the pipeline when that was touted in the 80's as being one of the things that made it fast. Sounds like 64 bit ARM has fixed all that, I look forward to getting my mits on one.
Probably close enough.
An A57 (the one we really want ) is supposed to be around 30% bigger than an A15 on a given process, so call them 2.1mm^2 each. They come in clusters of 4, so if you want more than 4 CPUs then you have some extra wiring to do, and with lots of cores you would want plenty of cache to feed them. Still, 8.5mm^2 for a basic quad core of ARM's current top of the range shows just how big Intel's 14.5mm^2 (on a smaller process) Haswell is. That big core isn't sloppyness either, that is just what it takes to make a single thread run that fast, and crunch that many SSE operations in a cycle. But at that size, if software that people care about does manage to scale better across multiple cores, then that core size is going to start looking like the most majestic paddle steamer of history. Awesome, impressive, and wtf were we ever thinking
Wonder if the Russians are thinking along these lines:
Multicore chips need to be mini-internets
Kind of similar to that HP "The Machine" announcement.
There are currently 1 users browsing this thread. (0 members and 1 guests)