If you are part of a large alliance, theres usually jump bridge routes to connect up all of your empire's assets. Inside of your network, transit really isnt an issue, aside from time roaming through enemy space. And theres always plenty to do then.
I'd pin anyone not in an alliance as someone who spends "most of their time gathering and flying through empty space with bugger all to do". Theres usually some sort of long term goal that has you floating through space, but the goal boils down to some static repetitive variant of "make money".
1. Stick to "safe" space and either run missions or do "industrial" tasks like building and inventing.
2. Join an alliance and exist on the edge of space defending and attacking.
The first I find to be insurmountalby boring. You're investing your time in building a richer character with no real ties to the universe, aside from market interaction. The second is whats fun, because you are part of a large collective action and are frequently playing with the other players towards large goals. And its fun precisely because the stakes are so high, because its to easy to get blown up and to go blow up others.
As for cost/investment;
For any given ship type in EVE, there are two variants: Tech 1 and Tech 2. Tech 2 costs 5-10x as much, and are across the board a bit better and have considerably better armor. EVE also has insurance. Insurance will usually cover a moderately equipped Tech1 ship pretty well, and insurance payouts dont vary between Tech1 and Tech2. If you dont mind flying mildly equipped Tech1, losing your ship in EVE is really not a bad loss at all. Generally, the role your ship is playing is more important than how good it is at its role as you are almost always just a small part of a group effort, so Tech1 is very viable.
The breakdown is that in PvP its a fine balance between shooting Tech1 ships which are easier to pick off and knock out of the fight versus picking on Tech2 ships that take longer to kill but put considerable financial hurt on the enemy player.
Theres very few game worlds with history worth tracking. "First 1000 players to complete XYZ quest"? Yeah whatever. For the most part these virtual worlds are totally static, modulo periodic content updates.
I'd be interested to hear what games have good data to track. Eve has outpost data and sovereignty data available via an API that tells you the status of the universe, although theres no long term historical data available from the company.
Planetside and maybe DAoC might have data worth tracking, but I have not played either. Anything where player controlled PvP regions make up a large part of the game world probably is similar.
We've heard this "OpenGL is very important to CAD" argument ad nom on the Khronos boards, and its here to haunt us like someone claiming DX is better because it provides an entire platform. Its another short sighted vacuous argument braced against empty air. Just stop it, stop it right now.
No CAD company is going to suffer inordinately because OpenGL got around to reforming the baseline to reflect modern hardware; on the contrary everyone will prosper because the spec will have been moved inline with how hardware works so companies will get more mileage from using OpenGL. For companies running legacy apps, there will continue to be backwards compatible OpenGL support deep into the future, it just wont be the kind of close to the metal optimization thats possible with a revised spec. Theres no "deal broken" by fixing OpenGL and making it a system that hardware companies can optimize.
Thats why I think this constantly flogged horse of an argument should be put down. Fixing a broken API is not a problem for CAD, CAD will adapt or huddle in its legacy shell. On the other hand, if OpenGL doesnt reform, it will cease being a viable API for hardware companies to support.
As for your quaint notion that games dont demand the latest technology, I think you should start looking through NV extensions and seeing what kind of documentations pops up to support these "optional" features NV went out of their way to develop. You should look at which of these "optional" features are adopted by ATI. Look at how many have gotten imported into ETX. Its all hardware developed and supported by these companies to help make games be top notch. They want developers to make the most of the hardware, so they constantly introduce new faster ways of doing things, and by and large gamers are the ones consuming those capabilities.
That being said, I'd actually stack the battle differently altogether: games/CAD v. embedded. All the consumer electronics devices we've just started making with fancy interfaces need display subsystems to drive them. OpenGL is rapidly penetrating this market, and I think OpenGL stands to be altered just as much as it stands to shake our consumer electronics world. Games and CAD will proceed apace backed by a revised API that hardware people can finally do a good job of accelerating again, meanwhile entirely unpredictable worlds will be opening and closing very rapidly in the consumer space, and OpenGL will be a major player in that field.
What you have is a misunderstanding, a mis-understanding that anyone gives half a rat about some platform locked kitchen sink of a library that has no bearing on the Linux Mac or mobile world.
Your much vaunted "many ways superior" unified platform recently switched over to using a standard spec, OpenAL, for audio.
Thankfully Intel was smart enough to give up and have hired PowerVR to build the integrated graphics for the upcoming Atom chipsets. X3100 was never going to fit in a mobile world, and, from my perspective, had no hope of ever getting with the times. Their DX10 performance is... ghastly. PowerVR at least will continue to invest in their stack and cares about making a viable graphics product.
You know its bad when the embedded world is more state of the art than 98% of PCs. The same PowerVR tech going into Atom is being put on-die with ARM chips. Intel was about to get paced by a mobile device, before they bought in.
And heres where I think it all comes together beautifully: if Intel doesnt "come to jesus" and stop holding up the entire computer market, I believe AMD will be able to leverage their far superior integrated chipsets to capture huge amounts of Intel's CPU business. OEMs are quite aware that the best bargian CPU in the world is useless without a display subsystem to make use of it, and AMD has been leading the charge on making an ecosystem of integrated chipsets, mobile devices, and really good low end graphics chips. Hybrid Power is a great example of how to leverage a reasonably fast very low power integrated chipset with a high performance video card.
All these details and circumstances aside, the bottom line is that I just cannot imagine the computer industry permitting Intel to keep getting by with such abysmal and useless crap. Its holding everything up, and its gonna change.
The most fundamental alteration packaged with OpenGL 3.0 is the addition of EXT_direct_state_access, which allows programmers to bypass a lot of the sticky "state" based behavior that's been the over-long kludge of OpenGL. Carmacks name is on it.
Thusfar the discussion has been decomposing in a mire of "CAD v. games" people, but thats all bull. ALL FUTURE EMBEDDED DEVICES NEED ACCELERATED GRAPHICS. I'm talking about cell phones, sat-nav, gps, gameboys, televisions: the entire world of consumer electronics all need accelerated graphical interfaces. OpenGL is the only spec for most of these devices yet it has been drifting further and further away from the underlying hardware.
The upcoming embedded processors all accelerate OpenGL to various degrees. ATI invested a lot in their embedded line, and have licensed their tech to dozens of companies. PowerVR is the other one: Intel licensed their graphics core for Atom since they cant make a decent core themselves. Once mobile systems have accelerated graphics, then you might see more people trying to capitalize on cross platform market. Serving Mac or Linux helps sales not one iota, but if you can relatively easily port to a cellphone and get good performance, many companies may reconsider using portable platforms.
I would be very interested to see Barthold Lichtenbelt's post. I went back to March but did not find it. I dont know what name he is posting with anymore. Any pointers/links to get me in the right direction would be appreciated.
EXT_direct_state_access is their answer to your state machine problems. Although it hasnt abolished state, the extension is designed to make it accessible: whereas previously programmers had to update selectors and latch in state, the EXT_direct_state_access extension attempts to, from what I can discern, provide easy on-demand access to various states, no context switching required.
As you are the only sane comment I've read from this entire thread, I'd be interested to hear what you think of EXT_direct_state_access.
5.6" 1.5lb Fujitsu U810 tablet/hybrid UMPC. Its a laptop yes but its tiny. It has a keyboard, but if boss-man needs to ever write anything, a 2.2lb 8.9" P1610D will serve far better. It too is pretty damned tiny. I have an older model P1120 and I cannot use it in public without getting a stream of people asking whether its really a laptop and commenting on how amazingly small new technology is (its a 4 year old laptop).
Anything you do on a phone now is going to be pretty hacky. A lot of business projectors run 1280x1024, so tell your boss to drop the pretty animations lest he melt his USB powered video output adapter. I dont think any phones have built in video out, so your boss has to add whatever bulk and weight that adapter conveys to his arsernal. For sure, video output is the weakest link on embedded processors, but the good news is the upcoming generation should be much better. OpenGL is coming to mobile in a big way and is really pushing the bar here, its just a matter of time before people realize how much sense it makes to hook their phone up to their widescreen. HDMI/DisplayPort makes the situation even better by coupling audio and video on the same cable. By mid 2010 I just cannot picture this not having become a quasi-standard feature on decent phones.
I dont see the relevancy of DPI. My ask is simple:
I want to be able to: 1. Open MS Word/OpenOffice 2. Set font size to 10 3. Set font size to 10.2 and have it adjust all the text 3. Set font size to 10.175 and have it adjust all the text 4. Set font size to 10.165 and have it adjust all the text
No mainstream/*nix operating system will render all these different font sizes as different sizes. I see no reason for this.
Scaling applications to DPI is a separate problem, and one I believe HTML & SVG are very good at. I dont see how DPI is relevant to accurate sub-pixel font rendering, with the very specific exception of printing. If you can clarify how your post relate to sub pixel rendering I would be much obliged.
I used to be a dark background/light text sort, raised on zenburn, but I've started using more and more light backgrounds / darker text varieties. The screenshots for a light blue background usually dont look that good, but in practice its pretty calm.
Also, I've gained a great appreciation for the "sets" of themes. DimGreen DimBlue Dim&c&c&c are a great series for example. The advantage is that I can open eight windows and easily identify which window is which piece of code, simply by looking at the background color.
Congradulations on being the first post to address the topic.
I have a 206BW at work and its color reproduction is atrocious. My Rally project management software's website is a pale maroon/brown color and it just comes out as light biege, its so awful.
IMO browns are the best place to see how bad your monitor sucks.
Also, LCD arms are way better than stands. The footprint is ~6 square inches, freeing that deskspace for keyboard or junk. At work I use a 30" wide monitor stand and have my keyboard under it, but thats only because my second display is my laptop.
Apple Windows and Linux all have pretty awful sub pixel rendering. Ideally you want a solution that lets you tweak the size of a font infinitely: you should be able to make any word or any letter any size what-so-ever. To my knowledge none of the common sub-pixel rendering systems provide this level of fine grained control.
The only good sub pixel rendering I've ever seen is well explained on Anti-Grain's Text Rendering page. This page explains how bad most sub-pixel rendering is, and how much better their open source method is.
I imagine for an LED clock it would depend on the duty cycle. Given that theres probably some ghosting, I'd think there wouldnt actually be any flicker for a lot of clocks.
Very cool, not that I expect to see a CRT ever again in my life but if and when I do and the poor user is at 60Hz I can now hand them peanuts to accompany my complaints about how their monitor is making my eyes bleed.
We'll definitely be seeing larger and larger caches on chip, but you cant fit very much. The Wii has ~24MB of fast onboard SRAM, which is where it does almost all its graphics work, but it has an unusually simple "1T" (one transistor ram) design to crap all that in. The PS3's SPE's have 16kb memory but insane bandwidth. Theres a place for onboard memory, but its limited.
No the real solution is bigger pipes to the outside world. Graphics cards are a great example, watching the GB/s climb year after year. AMD has had scalable memory for years via NUMA. You may have noticed CPU RAM speeds are rapidly climbing: we went from SDR 133 in mid 90's to DDR to PC2-6400 (266mhz ddr) mid 2000's (a trickle pace so far) to..... DDR3 at 1.3 GHZ in `08; four times what it was early/mid decade.
Intels Nehalem will release at 32GB/s per socket and climb to 50GB/s per socket. Graphics cards have been running ~140GB/s for a while (8800GTX).
yes there will be a lot of work to make software that can use multi core systems. we dont even have established practices for most software for doing this.
however i see no reason this would discriminate for x86. sparc has a 32 core design you can buy now. powerpc has a 8 way cpu announced. these are both more than x86 provides now. arm is close to releasing four way.
as for "single threads/multiple cores", processors already do this, its called superscalar design and out of order execution. expanding the out of order execution outside of the cpu core is feasible but i think returns will be laughably horrendously bad. one of the cpu makers was talking about trying it a little while ago.
Java lets you take advantage of multi-threaded functionality sure, but you have to manually instantiate all the tasks. You are imperatively telling it what to do. The syntax is hideous too, for any sort of high level parallelism library you end up re-creating function pointers and passing these tasks into your library. Its all perfectly doable and fits in the OO style, but its a manual process every time.
Declarative languages lend themselves much more naturally to schemes like lazy evaluation, which gives your runtime the opportunity to evaluate what you need to process, and then launch a bunch of independent tasklets to compute the answer. Once you are at the end and looking back on what you need to compute, holding the depenency graph, finding things capable of running in parallel should be very simple.
The GPU does not have "one GPU core". The NVidia GTX 280, for example, has 10 independent processing units. Each unit is comprised of 24 shaders, 8 texture units, some L1 memory, and access to RAM. All sub-units in the processing unit share a context and work towards completing the same task, but each of the 10 different units can be working on different things at the same time.
A failure in an Amd X4 will either turn it into an X3 (tri core) or a useless pile of purified silicon (some faults are non-recoverable, or there could be multiple)
Failures in an NVidia GTX 280 will turn it into an GTX 260 (8/10 working units) or a very very large piece of purified silicon. In this case, it goes from having 240 shaders / 80 texture mappers / 32 render units to 192/64/28.
Slashdot Mirror
If you are part of a large alliance, theres usually jump bridge routes to connect up all of your empire's assets. Inside of your network, transit really isnt an issue, aside from time roaming through enemy space. And theres always plenty to do then.
I'd pin anyone not in an alliance as someone who spends "most of their time gathering and flying through empty space with bugger all to do". Theres usually some sort of long term goal that has you floating through space, but the goal boils down to some static repetitive variant of "make money".
Theres two ways to play eve.
1. Stick to "safe" space and either run missions or do "industrial" tasks like building and inventing.
2. Join an alliance and exist on the edge of space defending and attacking.
The first I find to be insurmountalby boring. You're investing your time in building a richer character with no real ties to the universe, aside from market interaction. The second is whats fun, because you are part of a large collective action and are frequently playing with the other players towards large goals. And its fun precisely because the stakes are so high, because its to easy to get blown up and to go blow up others.
As for cost/investment;
For any given ship type in EVE, there are two variants: Tech 1 and Tech 2. Tech 2 costs 5-10x as much, and are across the board a bit better and have considerably better armor. EVE also has insurance. Insurance will usually cover a moderately equipped Tech1 ship pretty well, and insurance payouts dont vary between Tech1 and Tech2. If you dont mind flying mildly equipped Tech1, losing your ship in EVE is really not a bad loss at all. Generally, the role your ship is playing is more important than how good it is at its role as you are almost always just a small part of a group effort, so Tech1 is very viable.
The breakdown is that in PvP its a fine balance between shooting Tech1 ships which are easier to pick off and knock out of the fight versus picking on Tech2 ships that take longer to kill but put considerable financial hurt on the enemy player.
Theres very few game worlds with history worth tracking. "First 1000 players to complete XYZ quest"? Yeah whatever. For the most part these virtual worlds are totally static, modulo periodic content updates.
I'd be interested to hear what games have good data to track. Eve has outpost data and sovereignty data available via an API that tells you the status of the universe, although theres no long term historical data available from the company.
Planetside and maybe DAoC might have data worth tracking, but I have not played either. Anything where player controlled PvP regions make up a large part of the game world probably is similar.
What games do you think have data worth tracking?
We've heard this "OpenGL is very important to CAD" argument ad nom on the Khronos boards, and its here to haunt us like someone claiming DX is better because it provides an entire platform. Its another short sighted vacuous argument braced against empty air. Just stop it, stop it right now.
No CAD company is going to suffer inordinately because OpenGL got around to reforming the baseline to reflect modern hardware; on the contrary everyone will prosper because the spec will have been moved inline with how hardware works so companies will get more mileage from using OpenGL. For companies running legacy apps, there will continue to be backwards compatible OpenGL support deep into the future, it just wont be the kind of close to the metal optimization thats possible with a revised spec. Theres no "deal broken" by fixing OpenGL and making it a system that hardware companies can optimize.
Thats why I think this constantly flogged horse of an argument should be put down. Fixing a broken API is not a problem for CAD, CAD will adapt or huddle in its legacy shell. On the other hand, if OpenGL doesnt reform, it will cease being a viable API for hardware companies to support.
As for your quaint notion that games dont demand the latest technology, I think you should start looking through NV extensions and seeing what kind of documentations pops up to support these "optional" features NV went out of their way to develop. You should look at which of these "optional" features are adopted by ATI. Look at how many have gotten imported into ETX. Its all hardware developed and supported by these companies to help make games be top notch. They want developers to make the most of the hardware, so they constantly introduce new faster ways of doing things, and by and large gamers are the ones consuming those capabilities.
That being said, I'd actually stack the battle differently altogether: games/CAD v. embedded. All the consumer electronics devices we've just started making with fancy interfaces need display subsystems to drive them. OpenGL is rapidly penetrating this market, and I think OpenGL stands to be altered just as much as it stands to shake our consumer electronics world. Games and CAD will proceed apace backed by a revised API that hardware people can finally do a good job of accelerating again, meanwhile entirely unpredictable worlds will be opening and closing very rapidly in the consumer space, and OpenGL will be a major player in that field.
What you have is a misunderstanding, a mis-understanding that anyone gives half a rat about some platform locked kitchen sink of a library that has no bearing on the Linux Mac or mobile world.
Your much vaunted "many ways superior" unified platform recently switched over to using a standard spec, OpenAL, for audio.
Thankfully Intel was smart enough to give up and have hired PowerVR to build the integrated graphics for the upcoming Atom chipsets. X3100 was never going to fit in a mobile world, and, from my perspective, had no hope of ever getting with the times. Their DX10 performance is... ghastly. PowerVR at least will continue to invest in their stack and cares about making a viable graphics product.
You know its bad when the embedded world is more state of the art than 98% of PCs. The same PowerVR tech going into Atom is being put on-die with ARM chips. Intel was about to get paced by a mobile device, before they bought in.
And heres where I think it all comes together beautifully: if Intel doesnt "come to jesus" and stop holding up the entire computer market, I believe AMD will be able to leverage their far superior integrated chipsets to capture huge amounts of Intel's CPU business. OEMs are quite aware that the best bargian CPU in the world is useless without a display subsystem to make use of it, and AMD has been leading the charge on making an ecosystem of integrated chipsets, mobile devices, and really good low end graphics chips. Hybrid Power is a great example of how to leverage a reasonably fast very low power integrated chipset with a high performance video card.
All these details and circumstances aside, the bottom line is that I just cannot imagine the computer industry permitting Intel to keep getting by with such abysmal and useless crap. Its holding everything up, and its gonna change.
Clutter has a lot of the "2D layer" concepts you are looking for.
SDL does a respectable job of covering most of the rest of what you are asking for.
The most fundamental alteration packaged with OpenGL 3.0 is the addition of EXT_direct_state_access, which allows programmers to bypass a lot of the sticky "state" based behavior that's been the over-long kludge of OpenGL. Carmacks name is on it.
Thusfar the discussion has been decomposing in a mire of "CAD v. games" people, but thats all bull. ALL FUTURE EMBEDDED DEVICES NEED ACCELERATED GRAPHICS. I'm talking about cell phones, sat-nav, gps, gameboys, televisions: the entire world of consumer electronics all need accelerated graphical interfaces. OpenGL is the only spec for most of these devices yet it has been drifting further and further away from the underlying hardware.
The upcoming embedded processors all accelerate OpenGL to various degrees. ATI invested a lot in their embedded line, and have licensed their tech to dozens of companies. PowerVR is the other one: Intel licensed their graphics core for Atom since they cant make a decent core themselves. Once mobile systems have accelerated graphics, then you might see more people trying to capitalize on cross platform market. Serving Mac or Linux helps sales not one iota, but if you can relatively easily port to a cellphone and get good performance, many companies may reconsider using portable platforms.
I would be very interested to see Barthold Lichtenbelt's post. I went back to March but did not find it. I dont know what name he is posting with anymore. Any pointers/links to get me in the right direction would be appreciated.
EXT_direct_state_access is their answer to your state machine problems. Although it hasnt abolished state, the extension is designed to make it accessible: whereas previously programmers had to update selectors and latch in state, the EXT_direct_state_access extension attempts to, from what I can discern, provide easy on-demand access to various states, no context switching required.
As you are the only sane comment I've read from this entire thread, I'd be interested to hear what you think of EXT_direct_state_access.
5.6" 1.5lb Fujitsu U810 tablet/hybrid UMPC. Its a laptop yes but its tiny. It has a keyboard, but if boss-man needs to ever write anything, a 2.2lb 8.9" P1610D will serve far better. It too is pretty damned tiny. I have an older model P1120 and I cannot use it in public without getting a stream of people asking whether its really a laptop and commenting on how amazingly small new technology is (its a 4 year old laptop).
Anything you do on a phone now is going to be pretty hacky. A lot of business projectors run 1280x1024, so tell your boss to drop the pretty animations lest he melt his USB powered video output adapter. I dont think any phones have built in video out, so your boss has to add whatever bulk and weight that adapter conveys to his arsernal. For sure, video output is the weakest link on embedded processors, but the good news is the upcoming generation should be much better. OpenGL is coming to mobile in a big way and is really pushing the bar here, its just a matter of time before people realize how much sense it makes to hook their phone up to their widescreen. HDMI/DisplayPort makes the situation even better by coupling audio and video on the same cable. By mid 2010 I just cannot picture this not having become a quasi-standard feature on decent phones.
Wait your clocks are driven by a crystal? I thought thats what crystals were for, generating clocks! </drunk engineering on a thursday>
I dont see the relevancy of DPI. My ask is simple:
I want to be able to:
1. Open MS Word/OpenOffice
2. Set font size to 10
3. Set font size to 10.2 and have it adjust all the text
3. Set font size to 10.175 and have it adjust all the text
4. Set font size to 10.165 and have it adjust all the text
No mainstream/*nix operating system will render all these different font sizes as different sizes. I see no reason for this.
Scaling applications to DPI is a separate problem, and one I believe HTML & SVG are very good at. I dont see how DPI is relevant to accurate sub-pixel font rendering, with the very specific exception of printing. If you can clarify how your post relate to sub pixel rendering I would be much obliged.
I used to be a dark background/light text sort, raised on zenburn, but I've started using more and more light backgrounds / darker text varieties. The screenshots for a light blue background usually dont look that good, but in practice its pretty calm.
Also, I've gained a great appreciation for the "sets" of themes. DimGreen DimBlue Dim&c&c&c are a great series for example. The advantage is that I can open eight windows and easily identify which window is which piece of code, simply by looking at the background color.
Congradulations on being the first post to address the topic.
The definitive vim color scheme resource:
* http://www.cs.cmu.edu/~maverick/VimColorSchemeTest/ online vim color scheme browser for a variety of langauges (handily divided light and dark)
I have a 206BW at work and its color reproduction is atrocious. My Rally project management software's website is a pale maroon/brown color and it just comes out as light biege, its so awful.
IMO browns are the best place to see how bad your monitor sucks.
Also, LCD arms are way better than stands. The footprint is ~6 square inches, freeing that deskspace for keyboard or junk. At work I use a 30" wide monitor stand and have my keyboard under it, but thats only because my second display is my laptop.
Apple Windows and Linux all have pretty awful sub pixel rendering. Ideally you want a solution that lets you tweak the size of a font infinitely: you should be able to make any word or any letter any size what-so-ever. To my knowledge none of the common sub-pixel rendering systems provide this level of fine grained control.
The only good sub pixel rendering I've ever seen is well explained on Anti-Grain's Text Rendering page. This page explains how bad most sub-pixel rendering is, and how much better their open source method is.
I imagine for an LED clock it would depend on the duty cycle. Given that theres probably some ghosting, I'd think there wouldnt actually be any flicker for a lot of clocks.
Very cool, not that I expect to see a CRT ever again in my life but if and when I do and the poor user is at 60Hz I can now hand them peanuts to accompany my complaints about how their monitor is making my eyes bleed.
We'll definitely be seeing larger and larger caches on chip, but you cant fit very much. The Wii has ~24MB of fast onboard SRAM, which is where it does almost all its graphics work, but it has an unusually simple "1T" (one transistor ram) design to crap all that in. The PS3's SPE's have 16kb memory but insane bandwidth. Theres a place for onboard memory, but its limited.
No the real solution is bigger pipes to the outside world. Graphics cards are a great example, watching the GB/s climb year after year. AMD has had scalable memory for years via NUMA. You may have noticed CPU RAM speeds are rapidly climbing: we went from SDR 133 in mid 90's to DDR to PC2-6400 (266mhz ddr) mid 2000's (a trickle pace so far) to..... DDR3 at 1.3 GHZ in `08; four times what it was early/mid decade.
Intels Nehalem will release at 32GB/s per socket and climb to 50GB/s per socket. Graphics cards have been running ~140GB/s for a while (8800GTX).
yes there will be a lot of work to make software that can use multi core systems. we dont even have established practices for most software for doing this.
however i see no reason this would discriminate for x86. sparc has a 32 core design you can buy now. powerpc has a 8 way cpu announced. these are both more than x86 provides now. arm is close to releasing four way.
as for "single threads/multiple cores", processors already do this, its called superscalar design and out of order execution. expanding the out of order execution outside of the cpu core is feasible but i think returns will be laughably horrendously bad. one of the cpu makers was talking about trying it a little while ago.
Java lets you take advantage of multi-threaded functionality sure, but you have to manually instantiate all the tasks. You are imperatively telling it what to do. The syntax is hideous too, for any sort of high level parallelism library you end up re-creating function pointers and passing these tasks into your library. Its all perfectly doable and fits in the OO style, but its a manual process every time.
Declarative languages lend themselves much more naturally to schemes like lazy evaluation, which gives your runtime the opportunity to evaluate what you need to process, and then launch a bunch of independent tasklets to compute the answer. Once you are at the end and looking back on what you need to compute, holding the depenency graph, finding things capable of running in parallel should be very simple.
The GPU does not have "one GPU core". The NVidia GTX 280, for example, has 10 independent processing units. Each unit is comprised of 24 shaders, 8 texture units, some L1 memory, and access to RAM. All sub-units in the processing unit share a context and work towards completing the same task, but each of the 10 different units can be working on different things at the same time.
Current real world cases:
A failure in an Amd X4 will either turn it into an X3 (tri core) or a useless pile of purified silicon (some faults are non-recoverable, or there could be multiple)
Failures in an NVidia GTX 280 will turn it into an GTX 260 (8/10 working units) or a very very large piece of purified silicon. In this case, it goes from having 240 shaders / 80 texture mappers / 32 render units to 192/64/28.
as in, "we invented it, now we have to come up with some way to use it?"