A lot of this has to do with the pedestrian environment. People tend not to walk in areas that don't have sidewalks, don't have signalized crossings on busy streets or have wide four- or six-lane arterial roads. I once tried to walk from a suburban shopping mall across a medium-sized county throughway to another shopping mall on the other side of the street. It was not fun. I would not want to do that if I were elderly or had children with me. The geographical distance was short but the psychological distance was very long indeed.
Yeah that whole $100 per year I spend on maintaining my car (basically, changing the oil and air filter) really busts my balls.
Your maintenance costs are well over $100 per year. You aren't counting gasoline, for example.
Go ahead and have your public transport, but don't expect me to subsidize it. Let it pay for itself via ticket sales, the same way cars pay for themselves via gasoline/road taxes.
False. Fuel tax revenue does not come close to the funding level required to maintain roads. Most of the road dollars come from property taxes.
If I need to make an emergency trip at 3am, I can. Good luck finding a subway or bus at that hour (in my city they stop running at midnight.
Then your state needs to invest more in public transportation and do urban planning that puts people closer to their destinations.
Hallelujah! At least one other person gets it! People living near their desired destinations would help address many problems. Given our current energy crisis, we're going to see more density, not less. And that's a good thing.
It seems to me it would be much more practical to just give everyone one of these (gets 200mpg highway) for personal 1 or 2 human transport.
Opponents of public transportation systems often argue this very point. The problem is the fuel and maintenance costs make it impossible for low-income families to actually make use of the program. We know that public transportation works and we need to invest more in it, not less.
Here's the problem with fanciful ideas like this one. They're not just impractical (the author even admits to the maintenance issues by citing escalators), they actually hurt real progress.
Personal Rapid Transit is a poster child for this kind of delay tactic. A few naive PRT supporters are true believers who actually want a system that works. Most of the politicians who support PRT are heavily funded by oil, asphalt and other such industries and are against public transportation. They use PRT and other impractical ideas to suck resources from implementing systems like streetcars, LRT, bicycle infrastructure and high-frequency bus networks that are proven to work.
It's a classic case of the (seemingly) perfect being the enemy of the good. We are in a real energy crisis and we'd best start addressing the problem by making changes we already know work!
It's true that there are changes like that. But the average undergrad course does not hit them. Neither does the average graduate program.
That's why degrees from above-average institutions are so valuable. The quality of the graduate varies widely depending on the institution. Many institutions offer undergraduate research opportunities. Undergrads should take advantage of them.
From another angle: what's the purpose of an internship? Is it to get some work done or is it to learn something about the field? I have encountered people with very different philosophies about how to handle interns. It's exactly analogous to whether people see advanced degrees as valuable or not.
You're thinking of a university degree as an apprenticeship. It's not. If anything, a computing degree from most U.S. institutions isn't theoretical enough. Work skills come from doing work. That's why internships and the like are useful.
A university should be a place for asking, "why?" It should be a place to foster curiosity. Someone who knows how to ask the question and has initiative enough to get the answer is adaptable. That's invaluable.
Those Ph.D.s also happen to have bachelor degrees. Your point was that people with degrees beyond high school give up more quickly and aren't as creative. That's not true. To advance the state of the art one needs to know what the current state of the art is. Someone with only a high school degree probably doesn't even know what questions to ask. There are of course exceptions, but very few.
Self taught programmers appear to be a lot more innovative.
A properly trained programmer from a university with a cs degree that has worth usually are a lot more organized. They religiously document their code and come up with program designs that are scalable and reusable. But they are more likely to give up, they simply write code that requires least human effort, and a lot of the times their code are awfully slow. Most of them don't really question what they've been taught, and don't improve up on what they know.
Baloney. Show me one purely self-taught programmer who can correctly write the analysis and transformation engines to auto-parallelize and auto-vectorize code in a compiler. That requires serious understanding not only of computation models but of higher-level math as well. People working at that level are pretty damn innovative and persistent and yes, they all have college degrees, most of them Ph.D.s
Operating Systems -- The underlying principles are mostly the same
Algorithms -- New ones are constantly being discovered but the most popular ones have been the same for 30+ years mostly (the undergrad level ones are generally not newer things)...
Networking -- Some changes with wireless but most of the TCP/IP protocol that is taught in undergrad courses is the same
Discrete Math -- Again mostly the same for the past 30 years
Computer Organization -- Mostly this is the same (assuming the course on digital system design/k-maps/binary number systems/etc...)
My experience is that the ability to grasp the complexity of the above areas varies widely but generally the higher the degree, the better one is able to appreciate trends and anticipate them. The above areas only look static to one who hasn't studied them very deeply.
Operating Systems -- Manycore is causing huge upheaval. Scalability is not a solved problem.
Algorithms -- The algorithms aren't nearly as important as the ability to analyze complexity, a non-trivial skill most B.S. grads don't possess.
Networking -- Networking goes way beyond the internet. High-speed interconnect is a big area of research, for example.
Discrete Math -- Like complexity analysis, this is foundational knowledge. The concepts reappear over and over again. When one recognizes the patterns and how they interact across disciplines, interesting things can happen.
Computer Organization -- This is very much not the same as even 10 years ago. We've hit the frequency ceiling and manycore combined with power constraints is fundamentally shifting what is possible. Things that seemed silly a decade ago may be the right answer today and some things we've taken for granted as "good" probably aren't anymore.
A higher-level degree is not an advanced apprenticeship. It is about knowing what came before and anticipating what's coming next. Someone with a B.S. is likely to think he knows everything. Someone with a Ph.D. is smart enough to know how ignorant he is.
Not everyone needs or should get an advanced degree. But to claim that such degrees are worthless is the height of hubris
Surely it's a tricky balance. Closed-door negotiations can and have been abused. If there was a way to hold open meetings but prevent harmfully simple media headlines about it, we could make it work. The media used to be more responsible about these kinds of things.
And it's not just the media. Participants on all sides take public statements and actions out of context to score political points. Usually with a behind-the-scenes negotiations, all parties agree to keep things confidential. Of course our governor in Minnesota recently broke such a pledge. At the very least you need honest people in the process to make it work.
While I understand the sentiment, opening all meetings to the public would result in even more deadlock than we have now. Right now we're finding it impossible to make any significant changes to deal with some very significant problems. A lot of the problem is caused by the 24-hour news cycle where every action is scrutinized in immense detail. Public officials have a hard time making difficult decisions when this kind of pressure is on.
The public definitely should have open access to debates about the merits of proposals and the opportunity to participate in such debates via hearings. The public should also have open access to final agreements that are made. However, there is value in keeping at least some of the negotiation away from the cameras. It gives greater freedom to make compromises without fear of reprisal via incomplete (at best) coverage in the media.
Quite frankly, most people cannot take the time to fully understand the intricacies of every public policy debate. This doesn't mean those people are incapable of understanding the debate. But such understanding takes a real time commitment, which is hard to do with one full-time job, much less with two or three. The experts need somewhere to work in peace in quiet to actually get things done.
By "city" I meant metropolitan area. Lots of places in the US serve suburbs effectively with transit.
Park and rides work really well in the suburbs. They key insight to understand is that there are certain corridors that are heavily used. It doesn't really matter where people are living or where they're going to. What matters is where their travel patterns overlap. That's what mass transit takes advantage of. And it just so happens that in metropolitan areas, a lot of people tend to travel over the same routes, for historical reasons as much as anything else.
Rural areas are indeed challenging. You need a different type of service there. Regular route service is pretty inefficient. You need to balance that against the inconvenience of scheduling dial-a-rides. Most rural areas use a mix of service types.
Lots off good replies already, but I'll add my two cents anyway.
What do you need a computer that fast for?
Weather prediction (as you mentioned), climate modeling, nuclear fission and fusion modeling, data mining/searching, bioinformatics (protein folding, etc.), etc. The possibilities are endless.
mean, specifically, what can you do on something that fast that you couldn't do on one 1,000 (or 1,000,000) times slower? What kind of tasks need that much processing power?
It's actually not the processing power that is the unique characteristic of supercomputers these days. It's bandwidth, the ability to push vast amounts of data out to processing elements. This is why 100,000 Dell laptops hooked up with ethernet isn't a supercomputer, though the raw processing power may be in the ballpark. So we need these kinds of computers because the problems they work on involve processing exceedingly huge amounts of data.
For example, you normally hear about them being used for things like weather simulation. Well, what is it about weather simulation that requires so much work?
The models are getting more complex/accurate. For example, we used to think about modeling the air. Then we accounted for the effects of bodies of water on humidity, etc. Then we added in ocean currents, then land, then topographical features. Each advance requires new, more advanced models to be designed along with more data to be processed. All the while we are refining the level of detail. We used to predict weather on the scale of square miles or more, perhaps 3-4 days out. In 20 years we may be getting a prediction for the weather in the square foot around your garbage can 10 minutes from now. This kind of prediction is important not only for military applications but also things like civilian aviation and public safety (we just had 39 tornadoes in one day here in Minnesota).
I can't imagine what a dataset or algorithm would look like that would take so much power to chew through.
The datasets are enormous. Right now we're in the petaflops range. If we assume each flop takes two double-precision (64-bit) data inputs, that means we're processing 16 petabytes a second. Now these are peak numbers and most codes don't hit that sustained level of performance, but it gives you an idea of the scale.
There's a mixture of algorithms. A lot are of them are standard numerical codes, lots of matrix multiplies, etc. There are dusty decks that go back to Fortran 77 or earlier. Others are highly dynamic, involving pointer chasing, graph analysis etc. They are all massively parallel, running millions of threads simultaneously. Many of them use dynamic thread scheduling, moving work from one processor to another to balance out the load across all sockets. Usually the codes use MPI to talk across nodes (roughly equivalent to a socket) and OpenMP or a similar threading model within nodes. Hierarchical parallelism is becoming very important, as are languages designed with parallelism in mind (Co-Array Fortran and Universal Parallel C being the most prominent).
In this world, software is king. These massive beasts need to be usable which means compilers, libraries, debuggers, etc. must be pretty smart. What do you do when your million-thread program dumps core? How do you manage a million threads? You need compiler help to do a lot of it automatically.
For example public transportation systems that work well elsewhere don't work as well here. We simply have too many people living in low population density areas.
That myth has been debunked many times. If places like Dallas and Atlanta can do it, pretty much every reasonably-sized city can do it.
It's not just a fast debugger. Imagine having a fully-capable C++ parser in your debugger. This could potentially run rings around gdb for debugging C++.
To me, the most interesting possibility is the LLVM JIT. Right now it's very easy to peg gdb at 100% utilization by putting a conditional breakpoint at the wrong place. Now imagine the breakpoint condition being JITed into executable code and linked directly into the program being debugged.
I am still somewhat skeptical about libc++, but lldb potentially adds a lot to the table.
Interesting. I'm sure the gcc guys would like to see your example. Sometimes the compiler has to make tradeoffs. Strength reduction can in some cases increase register pressure so it's possible that in your case the compiler took a different strategy due to possible register spilling.
In any event, I have seen far too many codes where the programmer tried to "help" the compiler and ended up obscuring critical information. In my experience it's better to write the code to give the programmer the most information (i.e. express things naturally) and just let the compiler do its job.
No, longjmp does not unwind the stack. setjmp saves a machine context at a program point and longjmp jumps to that point and restores the machine context. Using setjmp/longjmp in C++ is deadly because destructors will not be called.
Any reasonable compiler should make array indexing equivalent to pointer arithmetic. Strength reduction should cause the compiler to produce essentially the same code.
Furthermore, and regardless of the above, there's no language-supported commonality between the containers themselves. So, for example, even though list and vector both have push_back(), there's no interface class, so you can't have a pointer to a push_back()able container.
Similarly, you can't extract a common interface to say list and list B*> even though push_back(&b) ought to work for both.
The C++ Standard Library (there is no such thing as STL any more) is primarily about generic programming, not class-based inheritance. They are orthogonal paradigms. The standard containers aren't designed to be used in class hierarchies. That's not what they're for.
The interesting thing is that the "ideal" C++ implementation of a semantic tree data structure as found in compilers would want to use both STL and inheritance: the STL would allow inherently ordered and unordered multiplicities to be represented efficiently while hiding the container algorithms (important if a program has 5000 top-level functions, for example). Inheritance would allow the tree to embody the classifications found in programs: for example literals are kinds of expressions, expressions are kinds of statements and so on.
Actually, I am writing a compiler-like tool in C++ and doing pretty much what you describe here. The standard containers and algorithms work great in this kind of environment. I have found no need to inherit from containers or have some kind of abstracted interface to the containers. I simply write generic code and it works. Even better, I can easily swap out various implementations of containers and algorithms to make space/time tradeoffs, etc.
It looks painfully apparent that C++0x will not address this "elephant in the room" and is instead content to faff around with syntactical sugar and "small picture" optimisations.
I'm not sure what elephant you're talking about. Can you clarify?
This is not flamebait. I live in Minnesota and the poster is right on. The man simply refuses to compromise at all. This is the same guy who stripped members of his own party of their committee assignments when they dared pass a transportation funding bill over his veto.
Further even in the nice cases like fluid flow, if one tries to do solution adaptive meshing, no uniform grids etc, the time step slows down so much the simulation takes too long even on a 100 million processor machine.
That's true in general. However, techniques like dynamic scheduling can help. Work stealing algorithms and other tricks will probably become part of the general programming model as we move forward. More and more of this has to be pushed to compilers, runtimes and libraries.
If Erlang isn't a "player" in the HPC space, why the !@# not?
Because it's not Fortran, C or C++. Really. That's the breaks. It's very hard to introduce a new language into a mature market.
It's functional nature also makes Erlang less attractive. While the theoretical benefits are great, various practical issues often get in the way. For example, how does one write a robust, efficient database in a functional language with single assignment? Finally, its dynamism comes at a cost that is often unacceptable to HPC users. Message passing has similar consequences.
And if it's not a player, what is, and what do I need to do to transition to it over the next decade or so?
Sounds like a pork program. What are "bio energy products", anyway. Ethanol?
I'm no expert on this, but I would guess the idea is to use the processing power to model different kinds of molecular manipulation to see what kind of energy density we can get out of manufactured biological goo. Combustion modeling is a common problem solved by HPC systems. Or maybe we can expore how to use bacteria created to process waste and give off energy as a byproduct. I don't know, the possibilities are endless.
It's striking how few supercomputers are sold to commercial companies. Even the military doesn't use them much any more.
Define "supercomputer." Sony uses them. So does Boeing. The auto industry uses clusters to model crashes, but I believe that's more limited by the design of the off-the-shelf software than anything. They could certainly run on supercomputer-class machines if the vendors ported them.
And the military uses them a lot. Much of the DOE research done on these machines is probably defense-driven.
Wait, what? You lost me. Are you from the future? How can you describe the state of the art as "primitive"?
Pretty easily, actually. There are lots of problems to solve, not the least of which is programming model. We're still basically using MPI to drive these machines. That will not cut it on a 100-million core machine where each socket has on the order of 100 cores. MPI can very easily be described as "primitive," as well as "clunky," "tedious" and "a pain in the ***."
How do we checkpoint a million-core program? How do we debug a million-core program? We are in the infancy of computing.
Slashdot Mirror
A lot of this has to do with the pedestrian environment. People tend not to walk in areas that don't have sidewalks, don't have signalized crossings on busy streets or have wide four- or six-lane arterial roads. I once tried to walk from a suburban shopping mall across a medium-sized county throughway to another shopping mall on the other side of the street. It was not fun. I would not want to do that if I were elderly or had children with me. The geographical distance was short but the psychological distance was very long indeed.
Yeah that whole $100 per year I spend on maintaining my car (basically, changing the oil and air filter) really busts my balls.
Your maintenance costs are well over $100 per year. You aren't counting gasoline, for example.
Go ahead and have your public transport, but don't expect me to subsidize it. Let it pay for itself via ticket sales, the same way cars pay for themselves via gasoline/road taxes.
False. Fuel tax revenue does not come close to the funding level required to maintain roads. Most of the road dollars come from property taxes.
If I need to make an emergency trip at 3am, I can. Good luck finding a subway or bus at that hour (in my city they stop running at midnight.
Then your state needs to invest more in public transportation and do urban planning that puts people closer to their destinations.
Hallelujah! At least one other person gets it! People living near their desired destinations would help address many problems. Given our current energy crisis, we're going to see more density, not less. And that's a good thing.
It seems to me it would be much more practical to just give everyone one of these (gets 200mpg highway) for personal 1 or 2 human transport.
Opponents of public transportation systems often argue this very point. The problem is the fuel and maintenance costs make it impossible for low-income families to actually make use of the program. We know that public transportation works and we need to invest more in it, not less.
Here's the problem with fanciful ideas like this one. They're not just impractical (the author even admits to the maintenance issues by citing escalators), they actually hurt real progress.
Personal Rapid Transit is a poster child for this kind of delay tactic. A few naive PRT supporters are true believers who actually want a system that works. Most of the politicians who support PRT are heavily funded by oil, asphalt and other such industries and are against public transportation. They use PRT and other impractical ideas to suck resources from implementing systems like streetcars, LRT, bicycle infrastructure and high-frequency bus networks that are proven to work.
It's a classic case of the (seemingly) perfect being the enemy of the good. We are in a real energy crisis and we'd best start addressing the problem by making changes we already know work!
It's true that there are changes like that. But the average undergrad course does not hit them. Neither does the average graduate program.
That's why degrees from above-average institutions are so valuable. The quality of the graduate varies widely depending on the institution. Many institutions offer undergraduate research opportunities. Undergrads should take advantage of them.
From another angle: what's the purpose of an internship? Is it to get some work done or is it to learn something about the field? I have encountered people with very different philosophies about how to handle interns. It's exactly analogous to whether people see advanced degrees as valuable or not.
You're thinking of a university degree as an apprenticeship. It's not. If anything, a computing degree from most U.S. institutions isn't theoretical enough. Work skills come from doing work. That's why internships and the like are useful.
A university should be a place for asking, "why?" It should be a place to foster curiosity. Someone who knows how to ask the question and has initiative enough to get the answer is adaptable. That's invaluable.
Those Ph.D.s also happen to have bachelor degrees. Your point was that people with degrees beyond high school give up more quickly and aren't as creative. That's not true. To advance the state of the art one needs to know what the current state of the art is. Someone with only a high school degree probably doesn't even know what questions to ask. There are of course exceptions, but very few.
Self taught programmers appear to be a lot more innovative.
A properly trained programmer from a university with a cs degree that has worth usually are a lot more organized. They religiously document their code and come up with program designs that are scalable and reusable. But they are more likely to give up, they simply write code that requires least human effort, and a lot of the times their code are awfully slow. Most of them don't really question what they've been taught, and don't improve up on what they know.
Baloney. Show me one purely self-taught programmer who can correctly write the analysis and transformation engines to auto-parallelize and auto-vectorize code in a compiler. That requires serious understanding not only of computation models but of higher-level math as well. People working at that level are pretty damn innovative and persistent and yes, they all have college degrees, most of them Ph.D.s
Operating Systems -- The underlying principles are mostly the same Algorithms -- New ones are constantly being discovered but the most popular ones have been the same for 30+ years mostly (the undergrad level ones are generally not newer things)... Networking -- Some changes with wireless but most of the TCP/IP protocol that is taught in undergrad courses is the same Discrete Math -- Again mostly the same for the past 30 years Computer Organization -- Mostly this is the same (assuming the course on digital system design/k-maps/binary number systems/etc...)
My experience is that the ability to grasp the complexity of the above areas varies widely but generally the higher the degree, the better one is able to appreciate trends and anticipate them. The above areas only look static to one who hasn't studied them very deeply.
A higher-level degree is not an advanced apprenticeship. It is about knowing what came before and anticipating what's coming next. Someone with a B.S. is likely to think he knows everything. Someone with a Ph.D. is smart enough to know how ignorant he is.
Not everyone needs or should get an advanced degree. But to claim that such degrees are worthless is the height of hubris
Surely it's a tricky balance. Closed-door negotiations can and have been abused. If there was a way to hold open meetings but prevent harmfully simple media headlines about it, we could make it work. The media used to be more responsible about these kinds of things.
And it's not just the media. Participants on all sides take public statements and actions out of context to score political points. Usually with a behind-the-scenes negotiations, all parties agree to keep things confidential. Of course our governor in Minnesota recently broke such a pledge. At the very least you need honest people in the process to make it work.
While I understand the sentiment, opening all meetings to the public would result in even more deadlock than we have now. Right now we're finding it impossible to make any significant changes to deal with some very significant problems. A lot of the problem is caused by the 24-hour news cycle where every action is scrutinized in immense detail. Public officials have a hard time making difficult decisions when this kind of pressure is on.
The public definitely should have open access to debates about the merits of proposals and the opportunity to participate in such debates via hearings. The public should also have open access to final agreements that are made. However, there is value in keeping at least some of the negotiation away from the cameras. It gives greater freedom to make compromises without fear of reprisal via incomplete (at best) coverage in the media.
Quite frankly, most people cannot take the time to fully understand the intricacies of every public policy debate. This doesn't mean those people are incapable of understanding the debate. But such understanding takes a real time commitment, which is hard to do with one full-time job, much less with two or three. The experts need somewhere to work in peace in quiet to actually get things done.
By "city" I meant metropolitan area. Lots of places in the US serve suburbs effectively with transit.
Park and rides work really well in the suburbs. They key insight to understand is that there are certain corridors that are heavily used. It doesn't really matter where people are living or where they're going to. What matters is where their travel patterns overlap. That's what mass transit takes advantage of. And it just so happens that in metropolitan areas, a lot of people tend to travel over the same routes, for historical reasons as much as anything else.
Rural areas are indeed challenging. You need a different type of service there. Regular route service is pretty inefficient. You need to balance that against the inconvenience of scheduling dial-a-rides. Most rural areas use a mix of service types.
Lots off good replies already, but I'll add my two cents anyway.
What do you need a computer that fast for?
Weather prediction (as you mentioned), climate modeling, nuclear fission and fusion modeling, data mining/searching, bioinformatics (protein folding, etc.), etc. The possibilities are endless.
mean, specifically, what can you do on something that fast that you couldn't do on one 1,000 (or 1,000,000) times slower? What kind of tasks need that much processing power?
It's actually not the processing power that is the unique characteristic of supercomputers these days. It's bandwidth, the ability to push vast amounts of data out to processing elements. This is why 100,000 Dell laptops hooked up with ethernet isn't a supercomputer, though the raw processing power may be in the ballpark. So we need these kinds of computers because the problems they work on involve processing exceedingly huge amounts of data.
For example, you normally hear about them being used for things like weather simulation. Well, what is it about weather simulation that requires so much work?
The models are getting more complex/accurate. For example, we used to think about modeling the air. Then we accounted for the effects of bodies of water on humidity, etc. Then we added in ocean currents, then land, then topographical features. Each advance requires new, more advanced models to be designed along with more data to be processed. All the while we are refining the level of detail. We used to predict weather on the scale of square miles or more, perhaps 3-4 days out. In 20 years we may be getting a prediction for the weather in the square foot around your garbage can 10 minutes from now. This kind of prediction is important not only for military applications but also things like civilian aviation and public safety (we just had 39 tornadoes in one day here in Minnesota).
I can't imagine what a dataset or algorithm would look like that would take so much power to chew through.
The datasets are enormous. Right now we're in the petaflops range. If we assume each flop takes two double-precision (64-bit) data inputs, that means we're processing 16 petabytes a second. Now these are peak numbers and most codes don't hit that sustained level of performance, but it gives you an idea of the scale.
There's a mixture of algorithms. A lot are of them are standard numerical codes, lots of matrix multiplies, etc. There are dusty decks that go back to Fortran 77 or earlier. Others are highly dynamic, involving pointer chasing, graph analysis etc. They are all massively parallel, running millions of threads simultaneously. Many of them use dynamic thread scheduling, moving work from one processor to another to balance out the load across all sockets. Usually the codes use MPI to talk across nodes (roughly equivalent to a socket) and OpenMP or a similar threading model within nodes. Hierarchical parallelism is becoming very important, as are languages designed with parallelism in mind (Co-Array Fortran and Universal Parallel C being the most prominent).
In this world, software is king. These massive beasts need to be usable which means compilers, libraries, debuggers, etc. must be pretty smart. What do you do when your million-thread program dumps core? How do you manage a million threads? You need compiler help to do a lot of it automatically.
For example public transportation systems that work well elsewhere don't work as well here. We simply have too many people living in low population density areas.
That myth has been debunked many times. If places like Dallas and Atlanta can do it, pretty much every reasonably-sized city can do it.
It's not just a fast debugger. Imagine having a fully-capable C++ parser in your debugger. This could potentially run rings around gdb for debugging C++.
To me, the most interesting possibility is the LLVM JIT. Right now it's very easy to peg gdb at 100% utilization by putting a conditional breakpoint at the wrong place. Now imagine the breakpoint condition being JITed into executable code and linked directly into the program being debugged.
I am still somewhat skeptical about libc++, but lldb potentially adds a lot to the table.
Interesting. I'm sure the gcc guys would like to see your example. Sometimes the compiler has to make tradeoffs. Strength reduction can in some cases increase register pressure so it's possible that in your case the compiler took a different strategy due to possible register spilling.
In any event, I have seen far too many codes where the programmer tried to "help" the compiler and ended up obscuring critical information. In my experience it's better to write the code to give the programmer the most information (i.e. express things naturally) and just let the compiler do its job.
No, longjmp does not unwind the stack. setjmp saves a machine context at a program point and longjmp jumps to that point and restores the machine context. Using setjmp/longjmp in C++ is deadly because destructors will not be called.
Any reasonable compiler should make array indexing equivalent to pointer arithmetic. Strength reduction should cause the compiler to produce essentially the same code.
Furthermore, and regardless of the above, there's no language-supported commonality between the containers themselves. So, for example, even though list and vector both have push_back(), there's no interface class, so you can't have a pointer to a push_back()able container. Similarly, you can't extract a common interface to say list and list B*> even though push_back(&b) ought to work for both.
The C++ Standard Library (there is no such thing as STL any more) is primarily about generic programming, not class-based inheritance. They are orthogonal paradigms. The standard containers aren't designed to be used in class hierarchies. That's not what they're for.
The interesting thing is that the "ideal" C++ implementation of a semantic tree data structure as found in compilers would want to use both STL and inheritance: the STL would allow inherently ordered and unordered multiplicities to be represented efficiently while hiding the container algorithms (important if a program has 5000 top-level functions, for example). Inheritance would allow the tree to embody the classifications found in programs: for example literals are kinds of expressions, expressions are kinds of statements and so on.
Actually, I am writing a compiler-like tool in C++ and doing pretty much what you describe here. The standard containers and algorithms work great in this kind of environment. I have found no need to inherit from containers or have some kind of abstracted interface to the containers. I simply write generic code and it works. Even better, I can easily swap out various implementations of containers and algorithms to make space/time tradeoffs, etc.
It looks painfully apparent that C++0x will not address this "elephant in the room" and is instead content to faff around with syntactical sugar and "small picture" optimisations.
I'm not sure what elephant you're talking about. Can you clarify?
This is not flamebait. I live in Minnesota and the poster is right on. The man simply refuses to compromise at all. This is the same guy who stripped members of his own party of their committee assignments when they dared pass a transportation funding bill over his veto.
Further even in the nice cases like fluid flow, if one tries to do solution adaptive meshing, no uniform grids etc, the time step slows down so much the simulation takes too long even on a 100 million processor machine.
That's true in general. However, techniques like dynamic scheduling can help. Work stealing algorithms and other tricks will probably become part of the general programming model as we move forward. More and more of this has to be pushed to compilers, runtimes and libraries.
If Erlang isn't a "player" in the HPC space, why the !@# not?
Because it's not Fortran, C or C++. Really. That's the breaks. It's very hard to introduce a new language into a mature market.
It's functional nature also makes Erlang less attractive. While the theoretical benefits are great, various practical issues often get in the way. For example, how does one write a robust, efficient database in a functional language with single assignment? Finally, its dynamism comes at a cost that is often unacceptable to HPC users. Message passing has similar consequences.
And if it's not a player, what is, and what do I need to do to transition to it over the next decade or so?
Probably OpenMP, Co-Array Fortran and UPC.
Sounds like a pork program. What are "bio energy products", anyway. Ethanol?
I'm no expert on this, but I would guess the idea is to use the processing power to model different kinds of molecular manipulation to see what kind of energy density we can get out of manufactured biological goo. Combustion modeling is a common problem solved by HPC systems. Or maybe we can expore how to use bacteria created to process waste and give off energy as a byproduct. I don't know, the possibilities are endless.
It's striking how few supercomputers are sold to commercial companies. Even the military doesn't use them much any more.
Define "supercomputer." Sony uses them. So does Boeing. The auto industry uses clusters to model crashes, but I believe that's more limited by the design of the off-the-shelf software than anything. They could certainly run on supercomputer-class machines if the vendors ported them.
And the military uses them a lot. Much of the DOE research done on these machines is probably defense-driven.
Wait, what? You lost me. Are you from the future? How can you describe the state of the art as "primitive"?
Pretty easily, actually. There are lots of problems to solve, not the least of which is programming model. We're still basically using MPI to drive these machines. That will not cut it on a 100-million core machine where each socket has on the order of 100 cores. MPI can very easily be described as "primitive," as well as "clunky," "tedious" and "a pain in the ***."
How do we checkpoint a million-core program? How do we debug a million-core program? We are in the infancy of computing.