As it happens, the hardware made to crunch graphics is also very good for crunching numbers and other things with regular structures. We can extend the general notion of the CPU as well. That's what Intel did with AVX and Larrabee. Both are valid and complementary approaches. A GPU uses a particular organization of memory and vector computation units to suck in bits from memory and spit it out the other side very quickly. ISA extensions like AVX and LNI marry the vector computation units to a more general memory system, providing more flexibility and the cost of less throughput. It's a tradeoff. Each model works very well for certain classes of problems.
Personally, I won't be using it or CUDA for much of anything. It's far too low-level, cumbersome and error-prone. It makes a good technology demonstration platform and people have managed to do some productive things with it but its days are numbered. The OpenMP accelerator subcommittee is doing some interesting stuff. That's the future along with automatic use of the accelerators by compilers. We are in the plugboard age of accelerators at the moment. We're going to exit that very quickly.
Somehow, someone has to figure a good standardized way to develop and run massively concurrent software, preferably based on an open standard.
Someone already has. There's even an accelerator subcommittee working to add nice compiler directives so we can do away with the ugly low-level OpenCL and CUDA programming. Fusion will not work without a decent programming model and associated tools.
There's more information on the GPU programming model in the HPCWire article. It is OpenMP directive-based, making it quite a bit easier to use than low-level CUDA and other such things.
You're forgetting things like PGAS and other higher-level parallel programming models. MPI is the dominant technology in use so these machines have to support it well. But they also support more future-looking tools.
bringing it into the realm of top supers like the Chinese Tianhe-1A
Uh, Cray already has machines in service that blow Tianhe-1A out of the water on real science. Tianhe-1A doesn't even exist anymore. It was a publicity stunt. Cray is already making the top supers. It's others that have to catch up.
We're not talking about Amtrak. We're talking about metro-region transit. Look at Portland. Look at Seattle. Look at Denver. These are all places that have reaped enormous ROI on transit investment.
Who ever said you could not choose? It's a strange definition of freedom to provide only one choice. We need more transit infrastructure to give people choice and we know that people choose it when given the option.
I hear responses like yours all the time. It's completely dishonest, putting words in people's mouths and not hearing what they're actually saying.
How disappointing. Production is not the problem, consumption is. Here's how to get energy under control: use less of it!
We've known for a very long time that the most cost-effective way to have the energy we need for the future is through conservation. Insulate houses. Replace windows. Use mass transit. As much as Republicans may hate it, President Carter was exactly right.
It's extremely disappointing to see the administration push hybrid/electric cars without making even more of a push for investment in transit infrastructure. The savings of $3000 over the life of a car with better mileage is dwarfed by the savings one gets from riding a bus or (even better) rail. The payoff for investment in public transit has been shown to be 7:1. For every dollar spent, $7 are returned in the form of efficiency, economic development and reduced congestion.
It's already impacted. The federal highway trust fund (where the gas tax goes) is bankrupt. They've had to supplement it with general fund dollars. But this is mostly due to our hugely overbuilt road network, not EVs and hybrids.
Remember that the pilots were also dealing with a massive storm and associated turbulence. It was not a stable situation. Plus the A330 doesn't have the physical feedback of the throttle controls moving as the autopilot adjusts speed. I can easily understand how the pilots could be confused.
The big question I had coming out of the NOVA program was, "why doesn't the computer automatically put the plane in a 5% pitch, 85% thrust configuration when it loses airspeed information?"
4) allowing functions to be invoked by passing them a tuple, instead of an arguments list. For example, a function foo(int a, double d) could have been called by foo({1, 3.14}) or foo(t) where t is std::tuple.
I agree this would be very useful. We can get something close to it with variadic templates but it's ugly.
5) removing the restriction of having to have a template prototype in order to specialize it.
I don't see much advantage here. Prototypes are easy to provide.
6) a way to enumerate the members of a struct, function stack record and translation unit variables at compile time.
Tuples provide something close for structs, anyway. There's a named tuple paper out there somewhere but I can't seem to find it via Google at the moment. Some introspection would certainly be useful.
8) named arguments.
This is #1 on my list of missing features. Default arguments as they stand are dangerous. It's too easy to add a non-default argument and have something that used to map to a default argument instead map to the new argument. This causes all sorts of problems. Default arguments should have been required to be used in conjunction with named arguments, so if a call does not pass all arguments, it would have to name the ones it does. I don't buy Bjarne's explanation for leaving them out in D&E. Other languages have solved those problems.
default parameters not only at the right side of a function header, but in any position.
This is another way to eliminate the danger of default arguments. If callers were required to add trailing commas for defaulted arguments, the problems go away.
Hrm...look here. If you're developing an x86 compiler these days and not adhering to this standard, you've pretty much locked yourself out of customers.
Well, it really depends on what you mean by template metaprogramming. The very first standard C++ library had template metaprogramming in it (the rebind member of allocators, iterator tags, etc.). The age-old "print something out at compile time" code is not very useful and makes a very poor example of what template metaprogramming is for.
Typelists were a turning point but it was only "by accident" in the sense that this was the first time people could use a C-like language to experiment with generic programming, and effectively this was the first time most people had even heard of generic programming. The generic programming experts have been talking about this stuff for a long time.
What is it about operator overloading that gets people all tied up in knots? An operator is just a function. It has a name, just like every other function. That name can be helpful or misleading, just like every other function. Operators are just functions. Really.
Does anyone actually use any of the features of C++?
Yes. So far I've used:
Right angle brackets
shared_ptr
unique_ptr
binders
Variadic templates
auto
And that's just in my own code, not counting features that libraries use (rvalue references, for example). I'd use a lot more if they were implemented in g++.
The next C++ standard is going to be a huge improvement in usability, especially for writing generic code.
Nope. Customers work hand-in-hand with vendors to make sure their codes will work. The "promise" is based on projections done by the vendor. Then the vendor presumably tests the codes as the machine is developed. If they don't work when the machine is shipped, the vendor pays penalties.
Slashdot Mirror
As it happens, the hardware made to crunch graphics is also very good for crunching numbers and other things with regular structures. We can extend the general notion of the CPU as well. That's what Intel did with AVX and Larrabee. Both are valid and complementary approaches. A GPU uses a particular organization of memory and vector computation units to suck in bits from memory and spit it out the other side very quickly. ISA extensions like AVX and LNI marry the vector computation units to a more general memory system, providing more flexibility and the cost of less throughput. It's a tradeoff. Each model works very well for certain classes of problems.
Personally, I won't be using it or CUDA for much of anything. It's far too low-level, cumbersome and error-prone. It makes a good technology demonstration platform and people have managed to do some productive things with it but its days are numbered. The OpenMP accelerator subcommittee is doing some interesting stuff. That's the future along with automatic use of the accelerators by compilers. We are in the plugboard age of accelerators at the moment. We're going to exit that very quickly.
Somehow, someone has to figure a good standardized way to develop and run massively concurrent software, preferably based on an open standard.
Someone already has. There's even an accelerator subcommittee working to add nice compiler directives so we can do away with the ugly low-level OpenCL and CUDA programming. Fusion will not work without a decent programming model and associated tools.
Yeah, you can't write a for loop in C and expect magically parallelization.
Sure you can, if you're not using pointers or are using restrict-qualified pointers and you have a good enough compiler.
There's more information on the GPU programming model in the HPCWire article. It is OpenMP directive-based, making it quite a bit easier to use than low-level CUDA and other such things.
Yep. Works great!
Jaguar.
As others have noted, IBM also makes machines that far surpass Tianhe-1A on real work. So does SGI.
Tianhe-1A was interesting for its intended purpose (Top-500) but it's a long way from being a productive tool.
You're forgetting things like PGAS and other higher-level parallel programming models. MPI is the dominant technology in use so these machines have to support it well. But they also support more future-looking tools.
bringing it into the realm of top supers like the Chinese Tianhe-1A
Uh, Cray already has machines in service that blow Tianhe-1A out of the water on real science. Tianhe-1A doesn't even exist anymore. It was a publicity stunt. Cray is already making the top supers. It's others that have to catch up.
We're not talking about Amtrak. We're talking about metro-region transit. Look at Portland. Look at Seattle. Look at Denver. These are all places that have reaped enormous ROI on transit investment.
Who ever said you could not choose? It's a strange definition of freedom to provide only one choice. We need more transit infrastructure to give people choice and we know that people choose it when given the option.
I hear responses like yours all the time. It's completely dishonest, putting words in people's mouths and not hearing what they're actually saying.
How disappointing. Production is not the problem, consumption is. Here's how to get energy under control: use less of it!
We've known for a very long time that the most cost-effective way to have the energy we need for the future is through conservation. Insulate houses. Replace windows. Use mass transit. As much as Republicans may hate it, President Carter was exactly right.
It's extremely disappointing to see the administration push hybrid/electric cars without making even more of a push for investment in transit infrastructure. The savings of $3000 over the life of a car with better mileage is dwarfed by the savings one gets from riding a bus or (even better) rail. The payoff for investment in public transit has been shown to be 7:1. For every dollar spent, $7 are returned in the form of efficiency, economic development and reduced congestion.
It's already impacted. The federal highway trust fund (where the gas tax goes) is bankrupt. They've had to supplement it with general fund dollars. But this is mostly due to our hugely overbuilt road network, not EVs and hybrids.
Remember that the pilots were also dealing with a massive storm and associated turbulence. It was not a stable situation. Plus the A330 doesn't have the physical feedback of the throttle controls moving as the autopilot adjusts speed. I can easily understand how the pilots could be confused.
The big question I had coming out of the NOVA program was, "why doesn't the computer automatically put the plane in a 5% pitch, 85% thrust configuration when it loses airspeed information?"
Flamebait? I challenge the moderator to justify that. It's not flamebait if it's true.
The world is not getting warmer, and at least if it is, God would make sure that it didn't get too hot so as not to harm us
You may joke, but there are people in power who actually believe this!
I am a Christian. Rep. Mike Beard's beliefs scare the crap out of me.
You will have a very slow cache.
Pshaw!
4) allowing functions to be invoked by passing them a tuple, instead of an arguments list. For example, a function foo(int a, double d) could have been called by foo({1, 3.14}) or foo(t) where t is std::tuple.
I agree this would be very useful. We can get something close to it with variadic templates but it's ugly.
5) removing the restriction of having to have a template prototype in order to specialize it.
I don't see much advantage here. Prototypes are easy to provide.
6) a way to enumerate the members of a struct, function stack record and translation unit variables at compile time.
Tuples provide something close for structs, anyway. There's a named tuple paper out there somewhere but I can't seem to find it via Google at the moment. Some introspection would certainly be useful.
8) named arguments.
This is #1 on my list of missing features. Default arguments as they stand are dangerous. It's too easy to add a non-default argument and have something that used to map to a default argument instead map to the new argument. This causes all sorts of problems. Default arguments should have been required to be used in conjunction with named arguments, so if a call does not pass all arguments, it would have to name the ones it does. I don't buy Bjarne's explanation for leaving them out in D&E. Other languages have solved those problems.
default parameters not only at the right side of a function header, but in any position.
This is another way to eliminate the danger of default arguments. If callers were required to add trailing commas for defaulted arguments, the problems go away.
Hrm...look here. If you're developing an x86 compiler these days and not adhering to this standard, you've pretty much locked yourself out of customers.
Well, it really depends on what you mean by template metaprogramming. The very first standard C++ library had template metaprogramming in it (the rebind member of allocators, iterator tags, etc.). The age-old "print something out at compile time" code is not very useful and makes a very poor example of what template metaprogramming is for.
Typelists were a turning point but it was only "by accident" in the sense that this was the first time people could use a C-like language to experiment with generic programming, and effectively this was the first time most people had even heard of generic programming. The generic programming experts have been talking about this stuff for a long time.
And suppose you're going through multiple parallel containers (what python calls "zip")?
Use the boost zip_iterator. Next question.
What is it about operator overloading that gets people all tied up in knots? An operator is just a function. It has a name, just like every other function. That name can be helpful or misleading, just like every other function. Operators are just functions. Really.
Does anyone actually use any of the features of C++?
Yes. So far I've used:
And that's just in my own code, not counting features that libraries use (rvalue references, for example). I'd use a lot more if they were implemented in g++.
The next C++ standard is going to be a huge improvement in usability, especially for writing generic code.
Nope. Customers work hand-in-hand with vendors to make sure their codes will work. The "promise" is based on projections done by the vendor. Then the vendor presumably tests the codes as the machine is developed. If they don't work when the machine is shipped, the vendor pays penalties.