Even the story seems to think that you're cheating if you use a GPU - when in fact, depending on the problems you're trying to solve, use of GPUs can make your computer more power-efficient, less expensive, and faster. OK, sure, if you want to argue that not every algorithm will map efficiently to a GPU, I'll accept that argument. But then you have to grant me the reverse argument; not every algorithm maps efficiently to CPUs. The problem in thinking here is just that the CPU is the "correct" way to do things, and sometimes you can "cheat" and use a GPU to do it faster. In reality, some problems just need parallel horsepower, and that's what the GPU excels at. Don't believe me? Well, here are some examples: Graphics (duh - why do you think they make GPUs?), n-body simulations (just need lots of number crunching here), and LINPACK (if you believe the people that complain that the GPU gets an unfair advantage - when really, the CPU is just at a disadvantage because of its architecture).
There can be a hurdle in learning how to rewrite your code to take advantage of the GPU, some of which might still be hanging around from the 1970s. But if you're going to spend millions of dollars on a new computer, you probably also have millions of dollars to spend on the research that you'll be doing on it. And if you've saved some of those millions of dollars by choosing GPUs over, say, 10x as many CPUs, then you can spend some of what you've saved (and will continue to save in lower power bills) on a programmer or two.
I don't intend this to attack the K Computer itself - hopefully, its architects listened closely to what the researchers wanted when designing it, and chose CPUs because they were the right choice for the programs that will be running on the computer. But the article (and some observers) seem rather biased, rather than recognizing that both CPUs and GPUs have strengths, and a supercomputer that includes both will likely be better at many problems than a computer that doesn't.
Of course, there's also the argument that *everything* on the Top500 list is biased, and not just the systems with GPUs, because not everybody's problem looks anything like LINPACK. So sometimes, something that's neither a CPU nor a GPU is the best choice (and whatever that something is might not run LINPACK well) - which is a very valid observation as well.
I'm pretty sure GPU's are Turing-complete, which means that they can implement any algorithm, just like any CPU. However, they'd be dog slow - just because they can crunch lots of data in parallel doesn't mean they'd be able to do the same if the instructions were in x86 format. Common things like branches aren't handled well on the GPU - and some studies have shown that about one in every four instructions is a branch. Also, there's lots of very specific hardware beyond the more general-purpose math-type stuff, like for supporting virtual memory and interrupts and things like that. Emulating all this would take huge amounts of software work. Add to this that any particular math-type operations that aren't supported would also have to be completely computed in software (as an example, imagine you had to implement square root in software - which you might, since the GPU's square root might be different precision from the CPU's), and you might start to see why this isn't a good idea. Even when it's done with hardware that is a better match for an x86 CPU (like what Transmeta did), it's a hard problem, and not necessarily beneficial.
Pennies? Apple is Samsung's second largest customer (Sony is #1), with Apple amounting to something in the neighborhood of 4-5% of their revenue, IIRC. You don't generally give the finger to a customer that big, even if they gave you the finger first.
I've been quietly wondering if this is just the public side to a private disagreement in the boardroom - perhaps Samsung is trying to raise flash or other component prices for Apple, or Apple wants to negotiate for lower prices than they already have. And, of course, if they get what they want, maybe this whole lawsuit nonsense will disappear too. And if their lower component price is disguised as a patent license from Apple, all the better to use as ammo against other companies who use Android.
It's optimized for a very high LUT/pin ratio, in a small, hot package, discounting macro blocks.
And that's a very good point. I've seen many, many designs that are far more I/O limited than logic-limited. I actually did a design once that used a very simple, cheap PLD; out of roughly 100 I/O pins, I think we had 4 or 5 unused, but we were only using something like 7% of the available logic. (Granted, we tried to maximize the I/Os that were in use - a couple might not have actually been tied to any logic, but we had them connected so that if we decided we could build logic off of them later, we didn't have to spin the PCB.) If you need something with a wide bus (like a DDR memory or something), then these may not have enough I/Os for you to use.
The whole idea of using this for an "upgradeable" chip seems rather unlikely though. First, because there's very little incentive for a company to offer upgrades, and several disincentives (reduced revenue from selling new gadgets, increased warranty costs from an upgrade failing, etc.). Also, the things that you most want to upgrade won't be reconfigurable. If a new video codec is released, sure, you could redo the logic so that you can encode and decode fairly fast - but you still can't upgrade the memory, or the camera, or the screen, or the wireless antenna, or any of the analog pieces (WiFi, Bluetooth, audio DAC, etc.), or whatever else might be attached to a gadget using this chip. So even if they do upgrade the logic, it won't get you most of the benefits of buying something new. On the other hand, this company might still carve out a niche within the niche that is the FPGA business for themselves, if they're very lucky.
...but it has fast context switching built-in. And you can't control when the contexts switch, they always go in order (as they should, since they're all statically assigned, and are different parts of a single problem, rather than separate problems).
For those that don't know how FPGAs work, here's a basic crash course: they have lots of blocks, each one has a look-up table (say a 4-LUT; 4 inputs, 1 output). The LUT is basically a "read-only" RAM with 4 address bits (so 16 addressable locations), and one data bit. The RAM can be rewritten (this is what is done when they program an FPGA), but it's fairly slow. Tabula changes it up a bit so that each addressable location is 8 bits instead of 1 bit. Since transistors are basically free on an FPGA (they're wire-dominated), this doesn't cost much, and it means that they can time-share pieces of silicon for different purposes without the penalty of reprogramming the chip. Then, each cycle, it'll pick a different one of the 8 bits (though the address, or inputs to the 4-LUT, may be changing at the same time).
It's a fairly straightforward idea, though there's a fair amount of complexity added to the design tools.
However, it's not free. You now have lots of high-speed logic, which is probably using tons of power, and it's switching frequently, which is using tons more power, and even when it's not, it's probably fairly leaky, using even more power. Effectively, you have a 1.6 GHz chip, but to you it seems like it's only running at 200 MHz - but it can do ~8 times more processing per silicon area. You might also think of it as being similar to the Pentium 4 integer units; they ran at twice the clock speed of the rest of the chip, so it seemed like there were twice as many of them (so a single IU could do an add in the first half of a core clock cycle, and a subtract in the second, computing two instructions per cycle).
So this chip is basically trading latency for computing power. The more operations you need to do, the slower it will run, because it'll take more of their folds to implement your logic.
I think it's closer to $100 million per acre, not $10 million, but what do I know? (That's based on ~$8000 per 12-inch wafer, which is an estimate I saw a year or two ago. Of course, maybe this guy is only getting 10% yield, in which case he's essentially right - and there's plenty of chips that are that bad, at least early in the product and process lifetime...)
This certainly happened to ATI; but I don't think ZFS was cut for the same reason. It was never "leaked" that Apple would use ZFS, just rumored, since they had a working alpha version (well, they called it a beta, but it was nowhere near beta quality - at least for the reliability one expects for a file system). It was publicly known that Apple was working on it in April 2006. The beta worked on 10.5.0, released in October 2007 - I even used it myself that fall for an Operating Systems project in school. Apple themselves announced that it would be available in 10.6 Server in about February 2009. However, references were later removed, and the project was publicly canned in October 2009, about 2 months after 10.6 was released. Ars Technica blames it on either licensing issues, or possibly Oracle's acquisition of Sun. A Sun employee more-or-less confirmed.
But yes, if there's a drop-in replacement for whatever Sony's making that's reasonably similar, or if the design process is early enough (eg if the iPhone 5 is coming out in fall, not summer, as has been rumored), then Sony probably won't be in it. And either way, they probably won't be in the next one, either. After that, it's anybody's guess; it takes Apple a year or two to cool off after a leak like that, typically.
Though it is possible that they'll ignore it; they didn't say anything about the phone itself, other than the camera resolution. (Granted, ATI didn't say anything except that there'd be new PowerMacs in a couple days either...)
Where else are we supposed to send the engineers that just don't quite cut it? Finance and business are great places for those kids that did really well in math and science in high school, and then discovered that they were terrible at engineering. I'm not saying that's where all finance and business people come from - just that an above-average number of bad engineers end up there (as well as some good engineers, and some people who never wanted to be engineers, etc.).
I've done some screenings on engineering students near graduation - some of them are just terrible! Now it's possible that some of them were just looking for the wrong type of engineering job when they came to see me, but I was asking questions that they would have known if they had paid attention in their required classes. Maybe I don't work in the area they like and excel in, and they'll find a job with a different company that suits them better. Or maybe they are horrible engineers, forget everything they learn in a class once the final exam is done, and need to find a different industry. The point is that there are a lot of them, and they'll be looking for jobs wherever they can find them. The ones that love and excel in engineering will probably end up there. The ones that stink, or love something else, or whatever, may end up in finance, business, or whatever. (Like one of my friends, who went into nursing after he finished mechanical engineering, once he realized that he didn't enjoy engineering - and thus probably wouldn't have made a good engineer if he had stayed.)
Go ahead and encourage the good ones to stay in engineering, but it's completely natural that some will always drift to other professions.
Like most Americans, I plan on waiting until disaster strikes, then I'll just order whatever I need via Amazon Prime.;-)
OK, OK, kidding. I'm an Eagle Scout, so I have at least marginal skills in survival, first aid, basketweaving, etc. And I'm a member of my company's Emergency Response Team, which also nets me periodic training (though not survival - more the sort of training that's useful in the 10 minutes from when you call 911 until the EMTs/firemen/police arrive - except they're so close to our office that they often make it to an emergency scene before I do). I have a supply of water and food, as well as camping gear that would be useful for filtering more water, cooking food, etc. And if the need arises to GTFO, and I can't wait for the traffic jam to die down, I'm prepared to bicycle, since it'll probably be faster.
600,001; my time was wasted being a grammar nazi on your improper use of 'effected' where you should've used 'affected', on a post that you never would have made if Chernobyl hadn't happened (so make that 600,002). Talk about the butterfly effect... Or maybe it's the inverse butterfly effect; a nuclear power plant explodes, and 25 years later, some guy (me) acts like an ass on the Internet.
Although, I should imagine the time span of +10MPH acceleration is a little shorter in an Impala than a Prius. Just guessing.....
Depending on which Impala, it might not be as big a difference as you'd imagine. The 180-hp 3389-lb 2003 base Impala has a 0-60 time of 8.9 seconds, while the 135-hp 3042-lb 2010 Prius has a 0-60 time of 9.8 seconds. If you add in the fact that the Prius is an eCVT and has no fixed gear ratios, the Prius might actually be faster to accelerate through a short range, if the Impala runs in an unfavorable gear or has to spend time shifting.
What you're probably familiar with is how a number of us Prius drivers move like slugs. That's just because accelerating fast is a great way to waste fuel. It's more obvious in a Prius because the mileage number drops faster (20% below 50 mpg is 40 mpg, 20% below 20 mpg is 16 mpg), and there are lots of displays to tell you how much gas you're using this instant, this trip, and the past half hour. However, other drivers have discovered this too; my brother drives a Volvo (an older S60 perhaps?) with a turbo. When he first got it, he loved to floor it as often as possible, enjoying the feeling of getting thrown back in your seat and the noise of the engine. These days, he's a bit more like grandma, once he noticed how much more often he had to fill up his car when he accelerated faster. Some of us will also coast for a long way to a red light, and laugh as others get frustrated behind us, floor it, zip around, only to have to slam on their brakes when they notice the red light too.
Of course, not every Prius driver is as annoying as us. I know one who is as crazy a driver as they come, and he pays for it by getting "only" 35 mpg.
I'm a Mac geek. I love Woz. But I trust Toyota more than I trust him on the matter, and here's why.
I own the same car as the one Woz noted his problem on; a 2010 Prius V (now called the Prius Five for 2011), with the Advanced Technology package. This means it has the radar cruise control.
The way cruise control works in some cars, like my dad's old Honda Accord is this: you press the button/lever to set a speed. Then, you press and hold a button/lever to accelerate. When you release the button, that's the new set speed, and there's no more acceleration.
In the Prius Woz and I have, it's a bit different; there's a screen a bit to the right of the speedometer that shows the radar cruise control status, including the set speed. Each time you nudge the cruise control stalk up, the set speed goes up by 1 mph. If you hold the stalk, it jumps up in increments of 5 mph. This has no relation to your current speed; if I'm at 50 mph, I can nudge it 5 times to set it to 55 mph, and my actual speed will only be at 51 mph by the time I'm done - so the car keeps accelerating until it gets to 55, a while later. If the car is at least 5 mph below the set speed, it'll open the throttle all the way, and accelerate much more rapidly than normal; so if you nudge the cruise control stalk up enough times, eventually it'll accelerate as fast as possible, until reaching your new setting. This is probably the "unintended acceleration" Woz experienced: After nudging it enough times, the difference between the set speed and the current speed is >5 mph, causing faster acceleration. In a different car, nudging it repeatedly like that would repeatedly accelerate a fraction of a mph, then keep the current speed as the new set speed, and would never continue accelerating past the time that you release the cruise control lever.
Steve also mentioned that nudging the lever down has no effect until he's done it 10 times or more - well of course not! While he's in his rapid (perhaps not intended by him, but it's what he told the car to do) acceleration, he nudges the lever down 10 times - and by that time, the car's speed and the set speed are back at the same level, so it stops accelerating.
I can't say I blame Steve though - he's not the type of guy that's likely to have the time to read the manual for his car (he admitted being very busy, otherwise I expect the nerd in him would be like the nerd in me, prompting him to read it at least twice). He probably assumed it behaves like his last car (or my dad's Honda Accord, or many other cars), where it will stop accelerating once you release the lever - rather than increasing the set speed on the screen while you hold the lever, and then continuing to accelerate to that speed after the lever has been released. (Rereading his comment on/., I note he also said this: "I am sure you can't turn the car off with the keyless power button..." This is certainly wrong - when the car is in motion, you can turn the car off by holding the power button for 3 seconds - another behavior mentioned in the manual.)
Finally, Steve told Wolf Blitzer that his problem was more akin to a button on the radio not working, as he could always cancel cruise control or press on the brakes and it would stop accelerating - so even if you believe his assessment, it's his personal opinion that it's a "surprising behavior", and not a safety issue. He also clarified that after he initially mentioned the problem, it became clear that his issue was distinct from the others reported in the media, and he didn't know if it was a widespread problem, or confined to his single car - but in any case, using the brakes always worked to stop the car, unlike most of the unintended acceleration cases in the media.
They still do this, and don't tell you (though you can probably figure it out if you look hard enough). A mid-range CPU is probably the same silicon as the high-end one, but with a core or two disabled, or some cache disabled, or the clock speed lower, or whatever else they may have needed to do. Ditto GPUs - the GeForce 570 appears to be the same silicon as a GeForce 580, but with one SM disabled, a narrower memory interface, and lower clocks. Each chip that is manufactured is slightly different from every other one - some have weak spots in a certain area, some have defects in certain places, some are faster, some are slower. Rather than throwing out a large percentage of the chips, they sell them as different models, where each chip is fully capable of working to the specs it is sold at. This means lower costs for everybody, because companies can sell almost all of their chips instead of throwing them away because they didn't meet the highest possible specifications.
If I were in the market for a computer with 2 SATA ports, I'd have no reservations buying one of these. It won't make a damn bit of difference if the other ports are not being used - in fact, not being used is quite likely to make them last longer, not that you'd notice.
And if you think that you've ever bought a "perfect" chip, or that the next spin of this chipset will be perfect, you've never seen the Errata list from a complex IC. Most big chips have tens or sometimes hundreds of known bugs. Most of those bugs are very minor. Some get workarounds in firmware, software, or drivers; some others may have no workaround, but the visible effect is minimal. Others are big (like a broken SATA port here) and necessitate a new spin of the chip to get the product the company wants. I've even seen errata that simply say "Feature X does not work. There is no workaround." when feature X was described in detail in the user guide (directed at the system designer, not the end user) and made up close to 10% of the manual. I've also seen errata that are identical between different manufacturers' products, making me wonder if they bought the IP for the broken feature from the same IP company, or if the IEEE standard for the feature was somehow non-functional, causing the feature to not work if the spec was properly implemented.
They are also speculating that the 261 mpg figure does not count the contribution of the batteries.
And even if it does, they may be rather optimistic about it. Chevy initially estimated the Volt's MPG (excluding electricity) to be 230 mpg. The actual sticker when it finally arrived at dealers says 93 mpg - and that's only if you only use electric power. If you ever use the full battery capacity, every mile after that is just 37 mpg. Similarly, Nissan pegged the Leaf at 367 mpg equivalent - a figure that has now dwindled down to 99 mpg equivalent, now that the testing method has been made more reasonable.
Of course, those figures are only if you drive like the EPA thinks you should. Most people don't get as high mileage as the EPA does. In any case, it'll be interesting to see just how much that 261 mpg drops once the vehicle gets anywhere close to being sold in the US......as if that will ever happen.
If you thought a high-voltage hybrid was dangerous......then you're a moron.
Seriously, there's about fifteen billion "dangerous" things in an average car - adding a small battery and a few wires doesn't change that. The total energy stored in the battery of most hybrids is about the same as the energy in a few tablespoons of gasoline. And unlike the parts of the car that carry your fuel, the high-voltage parts are clearly indicated with bright orange coloring. The airbags are probably more dangerous than the electricity. And the voltage isn't even that high - usually a couple hundred volts at most - the same range that is in every home and office.
I have no doubt that engineers can make a high-pressure tank quite safe. In fact, they've already done it. The Civic GX (a CNG-fueled passenger car) holds natural gas at up to 3600 psi. As do many other CNG-fueled vehicles, though it's much more commonly seen on buses. Just replace the rather flammable gas with a rather non-flammable one, and you're there. Seems easy enough to me...
Because most companies don't give straight shares, they give options.
Actually, I think options are falling out of favor in a lot of companies, and are being replaced with RSUs (Restricted Stock Units). It's basically the same deal, but you don't have to buy the option - it's just free stock that you are granted, and vests some number of years later. From my understanding, it can be taxed at a lower rate, is never worth zero, is still tied to the success of the company, and less shares are typically involved, so the dilution of stock is less.
That way, if the economy tanks and the company's stock price is just along for the ride, people whose compensation is largely stock-based don't get shafted. Of course, they'll do better if the company does better. It's also good for the average peon in the company that gets some (but not most) of his compensation in the form of stock - especially since the individual contributor has much less ability to sway the stock price than a CEO or a director.
Don't get your hopes up. Part of the agreement specifically amends the old chipset license to say that NVIDIA can't make chipsets for Sandy Bridge, Westmere, Nehalem, etc. chips that have a memory controller built-in. NVIDIA can make discrete graphics for these, of course, but the MCP line is D-E-D dead.
I've heard the same thing about fluorescent lights. But in both cases, it's wrong. The Prius, for example, gets rather incredible mileage because of (not despite) this. There could be increased wear, if the devices in question aren't designed properly, but the Prius handles all the starts and stops just fine. Average cheapo fluorescent lights, on the other hand, tend to burn out quickly if cycled on and off, though.
I commute by bike, and I can always hear a Prius (or Highlander or Camry or Lexus hybrid). They have a distinctive high-pitched whine from the high voltage electronics that's hard to miss. Unless of course, you're in a noisy environment, in which case adding more noise to the mix is NOT the solution...
In any case, of the people I've known to get hit by cars, and the accidents I have witnessed, exactly none would have been prevented with a little extra noise. Either the pedestrian was too distracted or thought that the driver knew to yield to them, and the driver didn't notice the pedestrian. If backing out is a particular problem, maybe backing cameras/sensors are the solution - but I've never known somebody to get seriously injured in a parking lot like that.
As for blind people, it's certainly true that any car might be hard to hear when coasting. However, last I checked, it's the driver's responsibility to stop for the pedestrian. And most of the "bell the hybrid" proposals only apply under 10 or 15 mph, above which tire noise is more apparent - and below which, the potential of life-threatening injury is fairly low. My proposal: Let he who hits a pedestrian be punished - and let the rest of us have our quiet cars and quiet streets. I know that my car is quiet - so I'm always keeping an eye out for pedestrians in pedestrian-heavy areas like parking lots or airports. And even if the pedestrian hears me - or if my car sounds like (or is) a Harley and they still don't hear me - it's still my fault if I hit them. Adding a noisemaker to cars isn't going to solve any real problems.
There *is* a programming model, there's just no *good* programming model. I'm very familiar with Verilog and VHDL, and use them in my job. That said, they're not languages that an average programmer can pick up and expect to get a good result - you have to learn how various constructs get converted to hardware, and how you are constrained by the hardware you are working with.
Similarly, I feel like OpenCL and the many parallel programming models suffer similar limitations (I've used Pthreads, OpenMP, MPI, Hadoop, TBB, Cilk, and others). There's a long way to go on research that will produce tools that can take the best advantage of modern hardware with the least required detailed knowledge about the target system.
For what it's worth, I did master's research involving including an FPGA (well, really coarsely-reconfigurable logic - so you get adders, multipliers, logic units, etc. that perform the same operations as in the CPU, but can rearrange the connections between them, eg string them together one way for one application, and a different way for another one) within a CPU as an integrated unit (alongside the integer, FP, and other units, as opposed to Intel's two-die approach). The idea would be to either have the OS detect some of the innermost loops of the program, or the application could specify them explicitly. Once it knows the innermost loop, it could convert the involved operations into a hardware configuration, and then the reconfigurable hardware could perform the operation more quickly than the CPU could alone. I think that's a better idea in that it doesn't have to require the programmer to know anything about how it works, though it also makes it more challenging to design the OS - but there are far fewer OS programmers than user-level programmers, so it'd be a net win.
As for your examples, I think that a raytracing accelerator would be better served by a much larger piece of hardware (an FPGA, GPU, or CPU) due to the compute requirements, plus higher bandwidth than PCIe x1. A custom CPU is doable, but it'd have to be extraordinarily simplified to fit in the fairly small FPGA (probably lacking 64-bitness, hyperthreading, out-of-order, superscalar, and all the other fun goodies that CPUs have now); a bigger CPU would need a bigger FPGA, likely quite a few FPGAs tied together. Making your own memory controller is doable, but since the CPU already has an integrated memory controller, I doubt you'd be able to get the CPU to use it - plus the limited bandwidth thing I mentioned. And ditto for your own cache; not to mention, FPGAs aren't typically known for their low latencies.
Most likely, they're going after the low-volume embedded market where it's not uncommon to have an FPGA or PLD to implement some glue logic and custom I/Os. One of my previous employers did just that; for example, implementing a Serial RapidIO link in an FPGA, and hooking it up to a CPU. Whether a x1 PCIe link is enough for the embedded market is questionable, though. But having the FPGA integrated on the die is a huge win for board area, which is often in high demand.
Probably not for anything you'd be interested in. Unless of course, you're interested in a slow CPU with slow (but custom) logic. If you want fast custom logic, or ridiculously low-power, you go with an ASIC (assuming you have either high volume, or can tolerate a high per-unit price). If you don't have a rather complex, repetitive calculation to do, you go with a regular CPU. If you do have a big calculation, you might consider a faster CPU or GPU, or at least something with a faster connection between the FPGA and CPU. If your calculation isn't particularly complex (eg something simple like adding two numbers), a CPU will already be faster and lower-power, assuming it has an instruction (or several) that implements the function you need.
In the end, Intel has just managed to invent yet another piece of hardware for which there is no good programming model. It's been how many years, and there is STILL no killer model for programming multiple core machines? Yes, there are many ways, but each has pretty significant disadvantages, and the vast majority of applications that people use see very minimal benefit from multiple cores (often because there's no great way to program for them without investing significant effort, see previous sentence).
This will be interesting for small embedded systems designers, who can come up with nifty ways to use the hardware, don't have large volumes, and can charge high prices since their customers have low-volume very specific needs. The rest of us will ignore it, forget it, and not shed a tear when Intel quietly discontinues the product.
There's nothing that's inherently "cheating" about using GPUs in a supercomputer. If your problem maps well to the hardware they have (and many large scientific and engineering workloads do), they can provide a huge speedup at a relatively low cost and relatively high performance per watt. After all, a GPU floating point throughput can be around 20 times faster than on a CPU; they're designed to do many things all at once (high throughput, high latency), while a CPU is designed to do one thing really really fast (lower throughput, lower latency). Recently, with multicore CPUs, the extra cores add performance very similarly to how a GPU would. If having a GPU is cheating, I'd surmise that having a multi-core CPU is cheating too.
It is true that LINPACK doesn't measure everything - it doesn't put a heavy stress on the interconnect, for example. Though if your problem is compute bound, you'd probably do well to find a way to minimize interconnect use to begin with. In any case, LINPACK measures *something* - it's a place to start comparing speeds, not the absolute truth of who will always be the fastest.
Besides, what's so important about the Top500? It gives somebody bragging rights for 6 months, or, if you're very lucky, a year or two, before something bigger comes along and squishes you. Not to mention, there are many supercomputers not on the list. If the NSA builds the world's largest supercomputer, they're probably not going to brag about how much compute power they have. They prefer the mystery, so outsiders have no idea what is within the realm of possibilities for them. I was at Cray once, and was told that they sometimes sell supercomputers into such secretive areas. The government (or whoever) will send a few guys to get trained about the computer, then it gets loaded onto trucks, and Cray never hears a thing about the computer ever again. No support calls, no upgrades, no idea where it even went to or what it's used for.
I agree with most of this, and what's said above and below... But the GPS in your car is exposed to extremes too - most people would be pretty pissed if every time they parked in the sun, their GPS wouldn't turn on. Last time I left my iPhone in the car on a hot day, it wouldn't turn on because it had overheated. The GPS worked fine, of course. I'd be willing to bet that's because it's designed for approximately the same environmental conditions as the ECU.
There are many good reasons for an ECU to be slow and old technology; there's not much need for hefty processing power, for one. And if you add more processing power, then you're probably adding more code, and more bugs, and more failures...
And in any case, I'd bet there are quite a few parts in your car that cost $150 or less to manufacture, yet a catastrophic failure would put your life in danger.
+. At my current job, I've primarily used two languages, neither of which I knew when I started. Then again, perhaps in Engineering, managers are more willing to hire based on your ability to think and learn new things than just what languages you already know - I can't say, as I've never been on the web (or software at all, for that matter) side of things. If I were hiring somebody anyway, I wouldn't care if they could use the particular language I need - it takes a week at most to really get moving, if you're good. What I'd look for is somebody that knows the concepts that I'm interested in; things like knowledge in the area of my business, possibly along with some knowledge of data structures or algorithms in any language at all. If they've got that and the ability to learn new things, that should be enough to get the job done. Of course, a good programmer that knows the language I need will beat out a good programmer that doesn't; but a good programmer that doesn't will beat out a bad programmer that does.
And how is the environment of a built-in GPS really significantly different from the ECU? Both are subject to the same dirty power supply, the same environmental extremes, and longer-than CE durability (eg 3-year+ warranty versus 1 for CE, typically). Perhaps it's not expected to be fail-safe, and perhaps it's not a huge deal if it dies after 8 years instead of 15, but I bet it's still built for automotive specifications. Heck, the NVIDIA Tegra is getting used in Audis now; that could be up to 700 MHz or more, though it's possible they might underclock it for better reliability and thermal tolerance.
Slashdot Mirror
Even the story seems to think that you're cheating if you use a GPU - when in fact, depending on the problems you're trying to solve, use of GPUs can make your computer more power-efficient, less expensive, and faster. OK, sure, if you want to argue that not every algorithm will map efficiently to a GPU, I'll accept that argument. But then you have to grant me the reverse argument; not every algorithm maps efficiently to CPUs. The problem in thinking here is just that the CPU is the "correct" way to do things, and sometimes you can "cheat" and use a GPU to do it faster. In reality, some problems just need parallel horsepower, and that's what the GPU excels at. Don't believe me? Well, here are some examples: Graphics (duh - why do you think they make GPUs?), n-body simulations (just need lots of number crunching here), and LINPACK (if you believe the people that complain that the GPU gets an unfair advantage - when really, the CPU is just at a disadvantage because of its architecture).
There can be a hurdle in learning how to rewrite your code to take advantage of the GPU, some of which might still be hanging around from the 1970s. But if you're going to spend millions of dollars on a new computer, you probably also have millions of dollars to spend on the research that you'll be doing on it. And if you've saved some of those millions of dollars by choosing GPUs over, say, 10x as many CPUs, then you can spend some of what you've saved (and will continue to save in lower power bills) on a programmer or two.
I don't intend this to attack the K Computer itself - hopefully, its architects listened closely to what the researchers wanted when designing it, and chose CPUs because they were the right choice for the programs that will be running on the computer. But the article (and some observers) seem rather biased, rather than recognizing that both CPUs and GPUs have strengths, and a supercomputer that includes both will likely be better at many problems than a computer that doesn't.
Of course, there's also the argument that *everything* on the Top500 list is biased, and not just the systems with GPUs, because not everybody's problem looks anything like LINPACK. So sometimes, something that's neither a CPU nor a GPU is the best choice (and whatever that something is might not run LINPACK well) - which is a very valid observation as well.
I'm pretty sure GPU's are Turing-complete, which means that they can implement any algorithm, just like any CPU. However, they'd be dog slow - just because they can crunch lots of data in parallel doesn't mean they'd be able to do the same if the instructions were in x86 format. Common things like branches aren't handled well on the GPU - and some studies have shown that about one in every four instructions is a branch. Also, there's lots of very specific hardware beyond the more general-purpose math-type stuff, like for supporting virtual memory and interrupts and things like that. Emulating all this would take huge amounts of software work. Add to this that any particular math-type operations that aren't supported would also have to be completely computed in software (as an example, imagine you had to implement square root in software - which you might, since the GPU's square root might be different precision from the CPU's), and you might start to see why this isn't a good idea. Even when it's done with hardware that is a better match for an x86 CPU (like what Transmeta did), it's a hard problem, and not necessarily beneficial.
Pennies? Apple is Samsung's second largest customer (Sony is #1), with Apple amounting to something in the neighborhood of 4-5% of their revenue, IIRC. You don't generally give the finger to a customer that big, even if they gave you the finger first.
I've been quietly wondering if this is just the public side to a private disagreement in the boardroom - perhaps Samsung is trying to raise flash or other component prices for Apple, or Apple wants to negotiate for lower prices than they already have. And, of course, if they get what they want, maybe this whole lawsuit nonsense will disappear too. And if their lower component price is disguised as a patent license from Apple, all the better to use as ammo against other companies who use Android.
It's optimized for a very high LUT/pin ratio, in a small, hot package, discounting macro blocks.
And that's a very good point. I've seen many, many designs that are far more I/O limited than logic-limited. I actually did a design once that used a very simple, cheap PLD; out of roughly 100 I/O pins, I think we had 4 or 5 unused, but we were only using something like 7% of the available logic. (Granted, we tried to maximize the I/Os that were in use - a couple might not have actually been tied to any logic, but we had them connected so that if we decided we could build logic off of them later, we didn't have to spin the PCB.) If you need something with a wide bus (like a DDR memory or something), then these may not have enough I/Os for you to use.
The whole idea of using this for an "upgradeable" chip seems rather unlikely though. First, because there's very little incentive for a company to offer upgrades, and several disincentives (reduced revenue from selling new gadgets, increased warranty costs from an upgrade failing, etc.). Also, the things that you most want to upgrade won't be reconfigurable. If a new video codec is released, sure, you could redo the logic so that you can encode and decode fairly fast - but you still can't upgrade the memory, or the camera, or the screen, or the wireless antenna, or any of the analog pieces (WiFi, Bluetooth, audio DAC, etc.), or whatever else might be attached to a gadget using this chip. So even if they do upgrade the logic, it won't get you most of the benefits of buying something new. On the other hand, this company might still carve out a niche within the niche that is the FPGA business for themselves, if they're very lucky.
...but it has fast context switching built-in. And you can't control when the contexts switch, they always go in order (as they should, since they're all statically assigned, and are different parts of a single problem, rather than separate problems).
For those that don't know how FPGAs work, here's a basic crash course: they have lots of blocks, each one has a look-up table (say a 4-LUT; 4 inputs, 1 output). The LUT is basically a "read-only" RAM with 4 address bits (so 16 addressable locations), and one data bit. The RAM can be rewritten (this is what is done when they program an FPGA), but it's fairly slow. Tabula changes it up a bit so that each addressable location is 8 bits instead of 1 bit. Since transistors are basically free on an FPGA (they're wire-dominated), this doesn't cost much, and it means that they can time-share pieces of silicon for different purposes without the penalty of reprogramming the chip. Then, each cycle, it'll pick a different one of the 8 bits (though the address, or inputs to the 4-LUT, may be changing at the same time).
It's a fairly straightforward idea, though there's a fair amount of complexity added to the design tools.
However, it's not free. You now have lots of high-speed logic, which is probably using tons of power, and it's switching frequently, which is using tons more power, and even when it's not, it's probably fairly leaky, using even more power. Effectively, you have a 1.6 GHz chip, but to you it seems like it's only running at 200 MHz - but it can do ~8 times more processing per silicon area. You might also think of it as being similar to the Pentium 4 integer units; they ran at twice the clock speed of the rest of the chip, so it seemed like there were twice as many of them (so a single IU could do an add in the first half of a core clock cycle, and a subtract in the second, computing two instructions per cycle).
So this chip is basically trading latency for computing power. The more operations you need to do, the slower it will run, because it'll take more of their folds to implement your logic.
I think it's closer to $100 million per acre, not $10 million, but what do I know? (That's based on ~$8000 per 12-inch wafer, which is an estimate I saw a year or two ago. Of course, maybe this guy is only getting 10% yield, in which case he's essentially right - and there's plenty of chips that are that bad, at least early in the product and process lifetime...)
This certainly happened to ATI; but I don't think ZFS was cut for the same reason. It was never "leaked" that Apple would use ZFS, just rumored, since they had a working alpha version (well, they called it a beta, but it was nowhere near beta quality - at least for the reliability one expects for a file system). It was publicly known that Apple was working on it in April 2006. The beta worked on 10.5.0, released in October 2007 - I even used it myself that fall for an Operating Systems project in school. Apple themselves announced that it would be available in 10.6 Server in about February 2009. However, references were later removed, and the project was publicly canned in October 2009, about 2 months after 10.6 was released. Ars Technica blames it on either licensing issues, or possibly Oracle's acquisition of Sun. A Sun employee more-or-less confirmed.
But yes, if there's a drop-in replacement for whatever Sony's making that's reasonably similar, or if the design process is early enough (eg if the iPhone 5 is coming out in fall, not summer, as has been rumored), then Sony probably won't be in it. And either way, they probably won't be in the next one, either. After that, it's anybody's guess; it takes Apple a year or two to cool off after a leak like that, typically.
Though it is possible that they'll ignore it; they didn't say anything about the phone itself, other than the camera resolution. (Granted, ATI didn't say anything except that there'd be new PowerMacs in a couple days either...)
Where else are we supposed to send the engineers that just don't quite cut it? Finance and business are great places for those kids that did really well in math and science in high school, and then discovered that they were terrible at engineering. I'm not saying that's where all finance and business people come from - just that an above-average number of bad engineers end up there (as well as some good engineers, and some people who never wanted to be engineers, etc.).
I've done some screenings on engineering students near graduation - some of them are just terrible! Now it's possible that some of them were just looking for the wrong type of engineering job when they came to see me, but I was asking questions that they would have known if they had paid attention in their required classes. Maybe I don't work in the area they like and excel in, and they'll find a job with a different company that suits them better. Or maybe they are horrible engineers, forget everything they learn in a class once the final exam is done, and need to find a different industry. The point is that there are a lot of them, and they'll be looking for jobs wherever they can find them. The ones that love and excel in engineering will probably end up there. The ones that stink, or love something else, or whatever, may end up in finance, business, or whatever. (Like one of my friends, who went into nursing after he finished mechanical engineering, once he realized that he didn't enjoy engineering - and thus probably wouldn't have made a good engineer if he had stayed.)
Go ahead and encourage the good ones to stay in engineering, but it's completely natural that some will always drift to other professions.
Like most Americans, I plan on waiting until disaster strikes, then I'll just order whatever I need via Amazon Prime. ;-)
OK, OK, kidding. I'm an Eagle Scout, so I have at least marginal skills in survival, first aid, basketweaving, etc. And I'm a member of my company's Emergency Response Team, which also nets me periodic training (though not survival - more the sort of training that's useful in the 10 minutes from when you call 911 until the EMTs/firemen/police arrive - except they're so close to our office that they often make it to an emergency scene before I do). I have a supply of water and food, as well as camping gear that would be useful for filtering more water, cooking food, etc. And if the need arises to GTFO, and I can't wait for the traffic jam to die down, I'm prepared to bicycle, since it'll probably be faster.
600,001; my time was wasted being a grammar nazi on your improper use of 'effected' where you should've used 'affected', on a post that you never would have made if Chernobyl hadn't happened (so make that 600,002). Talk about the butterfly effect... Or maybe it's the inverse butterfly effect; a nuclear power plant explodes, and 25 years later, some guy (me) acts like an ass on the Internet.
Although, I should imagine the time span of +10MPH acceleration is a little shorter in an Impala than a Prius. Just guessing.....
Depending on which Impala, it might not be as big a difference as you'd imagine. The 180-hp 3389-lb 2003 base Impala has a 0-60 time of 8.9 seconds, while the 135-hp 3042-lb 2010 Prius has a 0-60 time of 9.8 seconds. If you add in the fact that the Prius is an eCVT and has no fixed gear ratios, the Prius might actually be faster to accelerate through a short range, if the Impala runs in an unfavorable gear or has to spend time shifting.
What you're probably familiar with is how a number of us Prius drivers move like slugs. That's just because accelerating fast is a great way to waste fuel. It's more obvious in a Prius because the mileage number drops faster (20% below 50 mpg is 40 mpg, 20% below 20 mpg is 16 mpg), and there are lots of displays to tell you how much gas you're using this instant, this trip, and the past half hour. However, other drivers have discovered this too; my brother drives a Volvo (an older S60 perhaps?) with a turbo. When he first got it, he loved to floor it as often as possible, enjoying the feeling of getting thrown back in your seat and the noise of the engine. These days, he's a bit more like grandma, once he noticed how much more often he had to fill up his car when he accelerated faster. Some of us will also coast for a long way to a red light, and laugh as others get frustrated behind us, floor it, zip around, only to have to slam on their brakes when they notice the red light too.
Of course, not every Prius driver is as annoying as us. I know one who is as crazy a driver as they come, and he pays for it by getting "only" 35 mpg.
I'm a Mac geek. I love Woz. But I trust Toyota more than I trust him on the matter, and here's why.
I own the same car as the one Woz noted his problem on; a 2010 Prius V (now called the Prius Five for 2011), with the Advanced Technology package. This means it has the radar cruise control.
The way cruise control works in some cars, like my dad's old Honda Accord is this: you press the button/lever to set a speed. Then, you press and hold a button/lever to accelerate. When you release the button, that's the new set speed, and there's no more acceleration.
In the Prius Woz and I have, it's a bit different; there's a screen a bit to the right of the speedometer that shows the radar cruise control status, including the set speed. Each time you nudge the cruise control stalk up, the set speed goes up by 1 mph. If you hold the stalk, it jumps up in increments of 5 mph. This has no relation to your current speed; if I'm at 50 mph, I can nudge it 5 times to set it to 55 mph, and my actual speed will only be at 51 mph by the time I'm done - so the car keeps accelerating until it gets to 55, a while later. If the car is at least 5 mph below the set speed, it'll open the throttle all the way, and accelerate much more rapidly than normal; so if you nudge the cruise control stalk up enough times, eventually it'll accelerate as fast as possible, until reaching your new setting. This is probably the "unintended acceleration" Woz experienced: After nudging it enough times, the difference between the set speed and the current speed is >5 mph, causing faster acceleration. In a different car, nudging it repeatedly like that would repeatedly accelerate a fraction of a mph, then keep the current speed as the new set speed, and would never continue accelerating past the time that you release the cruise control lever.
Steve also mentioned that nudging the lever down has no effect until he's done it 10 times or more - well of course not! While he's in his rapid (perhaps not intended by him, but it's what he told the car to do) acceleration, he nudges the lever down 10 times - and by that time, the car's speed and the set speed are back at the same level, so it stops accelerating.
I can't say I blame Steve though - he's not the type of guy that's likely to have the time to read the manual for his car (he admitted being very busy, otherwise I expect the nerd in him would be like the nerd in me, prompting him to read it at least twice). He probably assumed it behaves like his last car (or my dad's Honda Accord, or many other cars), where it will stop accelerating once you release the lever - rather than increasing the set speed on the screen while you hold the lever, and then continuing to accelerate to that speed after the lever has been released. (Rereading his comment on /., I note he also said this: "I am sure you can't turn the car off with the keyless power button..." This is certainly wrong - when the car is in motion, you can turn the car off by holding the power button for 3 seconds - another behavior mentioned in the manual.)
Finally, Steve told Wolf Blitzer that his problem was more akin to a button on the radio not working, as he could always cancel cruise control or press on the brakes and it would stop accelerating - so even if you believe his assessment, it's his personal opinion that it's a "surprising behavior", and not a safety issue. He also clarified that after he initially mentioned the problem, it became clear that his issue was distinct from the others reported in the media, and he didn't know if it was a widespread problem, or confined to his single car - but in any case, using the brakes always worked to stop the car, unlike most of the unintended acceleration cases in the media.
They still do this, and don't tell you (though you can probably figure it out if you look hard enough). A mid-range CPU is probably the same silicon as the high-end one, but with a core or two disabled, or some cache disabled, or the clock speed lower, or whatever else they may have needed to do. Ditto GPUs - the GeForce 570 appears to be the same silicon as a GeForce 580, but with one SM disabled, a narrower memory interface, and lower clocks. Each chip that is manufactured is slightly different from every other one - some have weak spots in a certain area, some have defects in certain places, some are faster, some are slower. Rather than throwing out a large percentage of the chips, they sell them as different models, where each chip is fully capable of working to the specs it is sold at. This means lower costs for everybody, because companies can sell almost all of their chips instead of throwing them away because they didn't meet the highest possible specifications.
If I were in the market for a computer with 2 SATA ports, I'd have no reservations buying one of these. It won't make a damn bit of difference if the other ports are not being used - in fact, not being used is quite likely to make them last longer, not that you'd notice.
And if you think that you've ever bought a "perfect" chip, or that the next spin of this chipset will be perfect, you've never seen the Errata list from a complex IC. Most big chips have tens or sometimes hundreds of known bugs. Most of those bugs are very minor. Some get workarounds in firmware, software, or drivers; some others may have no workaround, but the visible effect is minimal. Others are big (like a broken SATA port here) and necessitate a new spin of the chip to get the product the company wants. I've even seen errata that simply say "Feature X does not work. There is no workaround." when feature X was described in detail in the user guide (directed at the system designer, not the end user) and made up close to 10% of the manual. I've also seen errata that are identical between different manufacturers' products, making me wonder if they bought the IP for the broken feature from the same IP company, or if the IEEE standard for the feature was somehow non-functional, causing the feature to not work if the spec was properly implemented.
Bottom line: yawn.
They are also speculating that the 261 mpg figure does not count the contribution of the batteries.
And even if it does, they may be rather optimistic about it. Chevy initially estimated the Volt's MPG (excluding electricity) to be 230 mpg. The actual sticker when it finally arrived at dealers says 93 mpg - and that's only if you only use electric power. If you ever use the full battery capacity, every mile after that is just 37 mpg. Similarly, Nissan pegged the Leaf at 367 mpg equivalent - a figure that has now dwindled down to 99 mpg equivalent, now that the testing method has been made more reasonable.
Of course, those figures are only if you drive like the EPA thinks you should. Most people don't get as high mileage as the EPA does. In any case, it'll be interesting to see just how much that 261 mpg drops once the vehicle gets anywhere close to being sold in the US... ...as if that will ever happen.
If you thought a high-voltage hybrid was dangerous... ...then you're a moron.
Seriously, there's about fifteen billion "dangerous" things in an average car - adding a small battery and a few wires doesn't change that. The total energy stored in the battery of most hybrids is about the same as the energy in a few tablespoons of gasoline. And unlike the parts of the car that carry your fuel, the high-voltage parts are clearly indicated with bright orange coloring. The airbags are probably more dangerous than the electricity. And the voltage isn't even that high - usually a couple hundred volts at most - the same range that is in every home and office.
I have no doubt that engineers can make a high-pressure tank quite safe. In fact, they've already done it. The Civic GX (a CNG-fueled passenger car) holds natural gas at up to 3600 psi. As do many other CNG-fueled vehicles, though it's much more commonly seen on buses. Just replace the rather flammable gas with a rather non-flammable one, and you're there. Seems easy enough to me...
Because most companies don't give straight shares, they give options.
Actually, I think options are falling out of favor in a lot of companies, and are being replaced with RSUs (Restricted Stock Units). It's basically the same deal, but you don't have to buy the option - it's just free stock that you are granted, and vests some number of years later. From my understanding, it can be taxed at a lower rate, is never worth zero, is still tied to the success of the company, and less shares are typically involved, so the dilution of stock is less.
That way, if the economy tanks and the company's stock price is just along for the ride, people whose compensation is largely stock-based don't get shafted. Of course, they'll do better if the company does better. It's also good for the average peon in the company that gets some (but not most) of his compensation in the form of stock - especially since the individual contributor has much less ability to sway the stock price than a CEO or a director.
Don't get your hopes up. Part of the agreement specifically amends the old chipset license to say that NVIDIA can't make chipsets for Sandy Bridge, Westmere, Nehalem, etc. chips that have a memory controller built-in. NVIDIA can make discrete graphics for these, of course, but the MCP line is D-E-D dead.
I've heard the same thing about fluorescent lights. But in both cases, it's wrong. The Prius, for example, gets rather incredible mileage because of (not despite) this. There could be increased wear, if the devices in question aren't designed properly, but the Prius handles all the starts and stops just fine. Average cheapo fluorescent lights, on the other hand, tend to burn out quickly if cycled on and off, though.
I commute by bike, and I can always hear a Prius (or Highlander or Camry or Lexus hybrid). They have a distinctive high-pitched whine from the high voltage electronics that's hard to miss. Unless of course, you're in a noisy environment, in which case adding more noise to the mix is NOT the solution...
In any case, of the people I've known to get hit by cars, and the accidents I have witnessed, exactly none would have been prevented with a little extra noise. Either the pedestrian was too distracted or thought that the driver knew to yield to them, and the driver didn't notice the pedestrian. If backing out is a particular problem, maybe backing cameras/sensors are the solution - but I've never known somebody to get seriously injured in a parking lot like that.
As for blind people, it's certainly true that any car might be hard to hear when coasting. However, last I checked, it's the driver's responsibility to stop for the pedestrian. And most of the "bell the hybrid" proposals only apply under 10 or 15 mph, above which tire noise is more apparent - and below which, the potential of life-threatening injury is fairly low. My proposal: Let he who hits a pedestrian be punished - and let the rest of us have our quiet cars and quiet streets. I know that my car is quiet - so I'm always keeping an eye out for pedestrians in pedestrian-heavy areas like parking lots or airports. And even if the pedestrian hears me - or if my car sounds like (or is) a Harley and they still don't hear me - it's still my fault if I hit them. Adding a noisemaker to cars isn't going to solve any real problems.
There *is* a programming model, there's just no *good* programming model. I'm very familiar with Verilog and VHDL, and use them in my job. That said, they're not languages that an average programmer can pick up and expect to get a good result - you have to learn how various constructs get converted to hardware, and how you are constrained by the hardware you are working with.
Similarly, I feel like OpenCL and the many parallel programming models suffer similar limitations (I've used Pthreads, OpenMP, MPI, Hadoop, TBB, Cilk, and others). There's a long way to go on research that will produce tools that can take the best advantage of modern hardware with the least required detailed knowledge about the target system.
For what it's worth, I did master's research involving including an FPGA (well, really coarsely-reconfigurable logic - so you get adders, multipliers, logic units, etc. that perform the same operations as in the CPU, but can rearrange the connections between them, eg string them together one way for one application, and a different way for another one) within a CPU as an integrated unit (alongside the integer, FP, and other units, as opposed to Intel's two-die approach). The idea would be to either have the OS detect some of the innermost loops of the program, or the application could specify them explicitly. Once it knows the innermost loop, it could convert the involved operations into a hardware configuration, and then the reconfigurable hardware could perform the operation more quickly than the CPU could alone. I think that's a better idea in that it doesn't have to require the programmer to know anything about how it works, though it also makes it more challenging to design the OS - but there are far fewer OS programmers than user-level programmers, so it'd be a net win.
As for your examples, I think that a raytracing accelerator would be better served by a much larger piece of hardware (an FPGA, GPU, or CPU) due to the compute requirements, plus higher bandwidth than PCIe x1. A custom CPU is doable, but it'd have to be extraordinarily simplified to fit in the fairly small FPGA (probably lacking 64-bitness, hyperthreading, out-of-order, superscalar, and all the other fun goodies that CPUs have now); a bigger CPU would need a bigger FPGA, likely quite a few FPGAs tied together. Making your own memory controller is doable, but since the CPU already has an integrated memory controller, I doubt you'd be able to get the CPU to use it - plus the limited bandwidth thing I mentioned. And ditto for your own cache; not to mention, FPGAs aren't typically known for their low latencies.
Most likely, they're going after the low-volume embedded market where it's not uncommon to have an FPGA or PLD to implement some glue logic and custom I/Os. One of my previous employers did just that; for example, implementing a Serial RapidIO link in an FPGA, and hooking it up to a CPU. Whether a x1 PCIe link is enough for the embedded market is questionable, though. But having the FPGA integrated on the die is a huge win for board area, which is often in high demand.
Probably not for anything you'd be interested in. Unless of course, you're interested in a slow CPU with slow (but custom) logic. If you want fast custom logic, or ridiculously low-power, you go with an ASIC (assuming you have either high volume, or can tolerate a high per-unit price). If you don't have a rather complex, repetitive calculation to do, you go with a regular CPU. If you do have a big calculation, you might consider a faster CPU or GPU, or at least something with a faster connection between the FPGA and CPU. If your calculation isn't particularly complex (eg something simple like adding two numbers), a CPU will already be faster and lower-power, assuming it has an instruction (or several) that implements the function you need.
In the end, Intel has just managed to invent yet another piece of hardware for which there is no good programming model. It's been how many years, and there is STILL no killer model for programming multiple core machines? Yes, there are many ways, but each has pretty significant disadvantages, and the vast majority of applications that people use see very minimal benefit from multiple cores (often because there's no great way to program for them without investing significant effort, see previous sentence).
This will be interesting for small embedded systems designers, who can come up with nifty ways to use the hardware, don't have large volumes, and can charge high prices since their customers have low-volume very specific needs. The rest of us will ignore it, forget it, and not shed a tear when Intel quietly discontinues the product.
+1.
There's nothing that's inherently "cheating" about using GPUs in a supercomputer. If your problem maps well to the hardware they have (and many large scientific and engineering workloads do), they can provide a huge speedup at a relatively low cost and relatively high performance per watt. After all, a GPU floating point throughput can be around 20 times faster than on a CPU; they're designed to do many things all at once (high throughput, high latency), while a CPU is designed to do one thing really really fast (lower throughput, lower latency). Recently, with multicore CPUs, the extra cores add performance very similarly to how a GPU would. If having a GPU is cheating, I'd surmise that having a multi-core CPU is cheating too.
It is true that LINPACK doesn't measure everything - it doesn't put a heavy stress on the interconnect, for example. Though if your problem is compute bound, you'd probably do well to find a way to minimize interconnect use to begin with. In any case, LINPACK measures *something* - it's a place to start comparing speeds, not the absolute truth of who will always be the fastest.
Besides, what's so important about the Top500? It gives somebody bragging rights for 6 months, or, if you're very lucky, a year or two, before something bigger comes along and squishes you. Not to mention, there are many supercomputers not on the list. If the NSA builds the world's largest supercomputer, they're probably not going to brag about how much compute power they have. They prefer the mystery, so outsiders have no idea what is within the realm of possibilities for them. I was at Cray once, and was told that they sometimes sell supercomputers into such secretive areas. The government (or whoever) will send a few guys to get trained about the computer, then it gets loaded onto trucks, and Cray never hears a thing about the computer ever again. No support calls, no upgrades, no idea where it even went to or what it's used for.
I agree with most of this, and what's said above and below... But the GPS in your car is exposed to extremes too - most people would be pretty pissed if every time they parked in the sun, their GPS wouldn't turn on. Last time I left my iPhone in the car on a hot day, it wouldn't turn on because it had overheated. The GPS worked fine, of course. I'd be willing to bet that's because it's designed for approximately the same environmental conditions as the ECU.
There are many good reasons for an ECU to be slow and old technology; there's not much need for hefty processing power, for one. And if you add more processing power, then you're probably adding more code, and more bugs, and more failures...
And in any case, I'd bet there are quite a few parts in your car that cost $150 or less to manufacture, yet a catastrophic failure would put your life in danger.
+.
At my current job, I've primarily used two languages, neither of which I knew when I started. Then again, perhaps in Engineering, managers are more willing to hire based on your ability to think and learn new things than just what languages you already know - I can't say, as I've never been on the web (or software at all, for that matter) side of things. If I were hiring somebody anyway, I wouldn't care if they could use the particular language I need - it takes a week at most to really get moving, if you're good. What I'd look for is somebody that knows the concepts that I'm interested in; things like knowledge in the area of my business, possibly along with some knowledge of data structures or algorithms in any language at all. If they've got that and the ability to learn new things, that should be enough to get the job done. Of course, a good programmer that knows the language I need will beat out a good programmer that doesn't; but a good programmer that doesn't will beat out a bad programmer that does.
And how is the environment of a built-in GPS really significantly different from the ECU? Both are subject to the same dirty power supply, the same environmental extremes, and longer-than CE durability (eg 3-year+ warranty versus 1 for CE, typically). Perhaps it's not expected to be fail-safe, and perhaps it's not a huge deal if it dies after 8 years instead of 15, but I bet it's still built for automotive specifications. Heck, the NVIDIA Tegra is getting used in Audis now; that could be up to 700 MHz or more, though it's possible they might underclock it for better reliability and thermal tolerance.