HardOCP News
[H] News
- Joined
- Dec 31, 1969
- Messages
- 0
C|Net has an interesting bit on the state of parallel computing and why software hasnt really caught up with the hardware yet.
![[H]ard|Forum](/styles/hardforum/xenforo/logo_dark.png){kind=logo}
Faster Chips Leaving Programmers In Their Dust
- Thread starter HardOCP News
- Start date
Did Intel really invent dual core only to have AMD beat them to the market with it? Or is this article just being a little Intel bias?
I think one thing that has hurt multicore is the same that has hurt 64-bit software. There are still too many older machines out there. Now when Blackcomb or Windows 7 or whatever they are wanting to call it this month, comes out this will be alittle different. By then your average person with a computer able to run the OS will have a dual core or better 64-bit machine as most of the machines on the market now are dual core 64-bit machines.
I think one thing that has hurt multicore is the same that has hurt 64-bit software. There are still too many older machines out there. Now when Blackcomb or Windows 7 or whatever they are wanting to call it this month, comes out this will be alittle different. By then your average person with a computer able to run the OS will have a dual core or better 64-bit machine as most of the machines on the market now are dual core 64-bit machines.
xX_Jack_Carver_Xx
2[H]4U
- Joined
- Jun 6, 2005
- Messages
- 2,542
Until the human brain of the programmers can "think" in parallel, I think we are not going to get alot of progress.
meantime, make single core 10Ghz a reality please.
meantime, make single core 10Ghz a reality please.
The problem is though, when you do this you're adding another layer of instructions, which slows everything down.
LOL @ "Intel bias"
Wow, I don't remember Intel making chips that heated up to over 1,000C. Maybe that's not an example of bias, just stupidity.article said:
(For someone ready to flame me, Intel and AMD can make 200W TDP chips in a 100C limit if they wanted to, but they don't.)I'm not laughing at you, just at another technically incompetent cnet article where the writer prints the dumbest things. The problem with "I'm first, I invented it" syndrome is that it ignores the realities like a product and a competing product that are in development for 3-4 years and released within months of each other didn't necessarily copy the other. There are obvious and not so obvious trends companies follow within an industry.
Back to the point, it's not really biased to state Intel is ahead in multi-/many-core research. They demonstrated the terrascale research processor running 80 cores running at over 1 TFLOP with very reasonable power consumption, and the not too far out Larrabee is a many-core x86 design. And arguably Intel and others can add complexity to external north bridges (successfully, at that from a performance standpoint on 4S+) that AMD can't integrate onto a CPU die.
Wow, I don't remember Intel making chips that heated up to over 1,000C. Maybe that's not an example of bias, just stupidity.
Don't worry, i to missed their cpus melting
Thing is thought that they really never said that they are ahead, nor would I disagree with that if they did. I just wasn't sure if Intel actually did start working on dual core first or if AMD did. AMD came up with the 64-bit architecture in use today in our "main stream" cpus and Intel just used it. Wasn't sure which way the dual core went. Athough I guess my question was flawed anyway as it should have been restricted to the x86 platform only as dual core cpus have been around longer than either intel's or amd's creations. Similar to how Intel had the Itanium as its 64-bit cpu but it didn't work with x86 software without emulation.
I've been mulling over this "parallel computing" software issue for more than awhile now and have reached the conclusion that if the programmers ever catch up the hardware, Intel and AMD will be history. I base that conclusion on the fact that IBM already has cell processors running at 5ghz - look it up - tho maybe cell processors don't do x86 processing - not sure about that. Anyway, something to ponder.
What really does blow chunks is that I have to consider leaving my uni for one of the richer (and therefore more expensive ones ) that were lucky enough to get funds to toss out some labs and teach us with some of the equipment we'll end up seeing.
I don't think software people who are already in the workforce slinging code have the time, money or energy to sit through classes or read manuals to see what the new procs have to offer...considering the market penetration some of them have.
) that were lucky enough to get funds to toss out some labs and teach us with some of the equipment we'll end up seeing.I don't think software people who are already in the workforce slinging code have the time, money or energy to sit through classes or read manuals to see what the new procs have to offer...considering the market penetration some of them have.
The only problem I see with 64 bit not catching up is strictly at the fault of Microsoft. If they would of released Vista as a 64 bit only OS, we would tons more software, I think they really dropped the ball on that.
I think that would have fucked them over on sales, despite the A64 providing a nice early introduction to 64-bit computing over the past years...I don't think they could have done that this gen.
Maybe next release, but 2006/2007 timeframe, I think they would've screwed themselves...maybe if there were some sort of market penetration chart? I remember reading a quote on bash... 'hey is my PC 64-bit?'...'is it shiny?'...'no'...'its not.'
Windows 7 is supposed to be completely 64-bit if I'm not mistaken, and so is the final release of Server 2007/2008. Though for something like this, a transition like they tried to do with Vista didn't really do anything. That kind of a switch needs to be done cold turkey, with the complete support of driver makers, etc.
Phoenix '97
Supreme [H]ardness
- Joined
- May 4, 2000
- Messages
- 4,539
I wonder if this would be a good time to be "in the know" as far as parallel programming goes, not only in languages like C, but also for other hardware accelerators such as FPGAs and GPGPUs, as far as the job market is concerned.
Desdichado
Limp Gawd
- Joined
- Apr 22, 2006
- Messages
- 331
I'm pretty sure that cell is a RISC processor, which means it's easier to get it running at higher speeds, because there are less possible commands, leading to lower latencies.
I was talking with Chris Melissinos, the head of Sun's gaming division, about this the other day, and he essentially agreed with what Jack Carver said... the issue is that programmers think in a single thread. To be an effective multi-threaded programmer, you have to be able to break what you're doing up into independent, roughly equally sized pieces, which is difficult at best.
The solution he presented was for developers to create environments that automatically do this multithreading for the programmer, which is what Sun has done with their DarkStar project. It's an interesting idea, but I have trouble seeing it catch on with major developers, who tend to develop their own engines in-house.
In the mean time, I tend to see it as good for the consumer, because it means that, while gaming at least, we can get by with a dual-core cpu. Since they're generally cheaper, that saves me money, which I'm a big fan of.
The cell processor has a 64 bit Power PC chip (which is risc based) at it's core with like 8 other cores (co-processors? ) doing other things.
I would compare it to probably the nvidia GPU core with stream processors maybe?
So technically, no, it can't run x86 code natively.
It would have worked for Apple but, they made the switch to Intel. I just wonder what it would have been like if they stuck with it.
The cell processor seemed to me like it was designed more for graphics and maybe physx work with the CPU work being done by the PPC chip?
I would compare it to probably the nvidia GPU core with stream processors maybe?
So technically, no, it can't run x86 code natively.
It would have worked for Apple but, they made the switch to Intel. I just wonder what it would have been like if they stuck with it.
The cell processor seemed to me like it was designed more for graphics and maybe physx work with the CPU work being done by the PPC chip?
Maybe they could just make their applications to where the thread based systems are able to run on any of the threads and let the OS or the application, do load balancing.
They could have the terrain and stuff on a thread and their AI on another thread and so on. If the cores exist, then that thread goes to core 2 or 4, the next one goes to core 3 or whatever.
I have no idea about multicore programming so not to sure here. I grew up with single core programming and retired from it before multicore.
They could have the terrain and stuff on a thread and their AI on another thread and so on. If the cores exist, then that thread goes to core 2 or 4, the next one goes to core 3 or whatever.
I have no idea about multicore programming so not to sure here. I grew up with single core programming and retired from it before multicore.
Manny Calavera
2[H]4U
- Joined
- Jun 10, 2004
- Messages
- 3,986
Whats more shocking is that MS has no intentions of doing that with the next version of Windows ! We will still be tied to 32 bit 'legacy code' even then.I would be willing to bet
that sales would not at all be hampered then (4 to 5 years from now),as most if not all will have a cpu with a 64 bit abilities.Certainly the potential install base that far out from now will be high enough for MS to do it.
While I don't agree that Vista should have been 64-bit only, I do think they should have positioned 32 vs 64 bit
Vista the same way they are doing it with 2008 Server where 64-bit is the default and 32-bit is optional.
Desdichado
Limp Gawd
- Joined
- Apr 22, 2006
- Messages
- 331
Wait, did you just say Sun has a gaming division?
Yeah, they actually do, although no one has heard of it, possibly for good reason. They have yet to do anything major, and don't actually develop any games on their own, afaik. Basically, they are working on creating an ide and game server for java games. I've seen a couple of games developed on it, and they actually looked pretty good (there was a rts chris showed off that had pretty nice graphics). The website is http://www.projectdarkstar.com/. They mostly want to do mmorpgs.
@cringe
I looked up the SPUs in the cell, and they have 191 instructions, many of which are inter-core communication type instructions. They also have 4 floating point units capable of a total of 32 GFLOPS and 4 integer units capable of a total of 32 GOPS. It also uses vector processing, meaning that multiple instructions can be to different cores with a single instruction. To me at least, it looks like it's actually using a Princeton architecture.
As shown by the PS3, it can function as a independent processor, but looking at it, I'm going to agree with you that it would seem better suited for standalone physics/rendering type work. It might actually give a 8800 a run for it's money, since those top out around 500 GFLOPS (when using shaders), and the cell SPUs are probably more versatile.
Can anyone build me a pcie cell processor card?
I hate to break it to you, but since the pentium all intel X86 CPUs have been RISC inside. Early on they took a decent sized hit from the conversion unit (took alot of space that could've been l1 cache) but as processes have continued to shrink the space needed has become insignificant.
There are. Functional programming languages (ocaml, erlang, haskel) are inherently stateless and parallelize automatically. Ericson wrote erlang so that they could update firmware on thier telecom hardware *without* having to pause/shut it down. Google uses functional programming to parallelize their backend. The problem is that functional langauges don't mesh well with how most people think which make them difficult to work with.
Desdichado
Limp Gawd
- Joined
- Apr 22, 2006
- Messages
- 331
Granted... they are technically RISC, albeit of a different kind. My intention was to point out that the cell SPUs are (to the best of my knowledge) pure RISC, and therefore don't have decode unit to slow them down. Besides which, they have less than half the instructions of most modern x86 CPUs. So it would still be easier from a purely architectural standpoint to run them at a higher clock. But yes, both AMD and Intel's current lineups are internally RISC.
Does anyone know if either AMD or Intel internally split instructions to different cores in conversion to RISC? If not, that would be an interesting way to go about it, although I'm guessing right now that each core has its own conversion unit. I can think of some cases where that would be a very efficient way to go about splitting something up... instructions like MPSADBW that do multiple independent things at the same time. Just something that came to mind... any thoughts?