By lifespan, I don't mean when production starts to when production ends. I mean from when PS3s go on sale to when major developers cease developing and marketing games for the PS3, and there is a PS3 successor.
Sony is hoping for a 10 year lifetime on the PS3 (sorry, can't cite a source, it's a random tidbit I read somewhere), so development methods for it might actually have time to become mature.
That's because the Linux kernel and everything compiled for it don't use the SPEs (the Cell vector cores), and it's the SPEs that make the Cell processor powerful. Nor can they, really. Most of what the kernel and other applications do will not benefit from a vector processor. However, graphics and scientific computing will.
Stroustrup's original goal was for a language that allowed OO programming and was still suitable for serious systems programming. I think he makes that clear in The Design and Evolution of C++. And are you aware that the original name was, in fact, C with Classes?
I like functional programming, but it's been around for a long, long time. The only language older than LISP is Fortran. I think if the "functional programming revolution" was going to happen, it would have already happened.
No, I don't think it's telling that Stroustrup finds it useful to explain how he decided what did and did not get into the language. The mere fact that people shout about something doesn't mean that they have a valid complaint.
As far as C goes, yes, you can write obtuse code with non-obvious semantics. But that's true of any useful language. Much of what you blame on C is a result of the fact that it's basically a high level assembler. The fact that manipulating hardware can be confusing is not the fault of C.
Simply using a std::vector won't do the job. But I think it's reasonable to implement what you described with templates with checks at compile time - but I'm not sure as I have not done it.
Again, Stroustrup was concerned with runtime effeciency. C++ was intended to be a systems programming language with high level abstraction mechanisms. It was not intended to be a language with runtime checks for correctness. All of the overheads you mention are real and I won't disagree with them. I think that there are many domains where checked languages are appropriate and desirable. Since what you want runs contrary to the original design goals of the language, then I just can't consider your complaints valid.
That is interesting, and thanks for the pointer to Spec# (I'm re-reading the tech report on Singularity for my quals, so it's relevant to me at the moment). But Stroustrup makes clear in D&E that any overhead was unacceptable. While checks can be done at compile time, not all of it can. (I think that most difficult to spot errors are going to happen in places where it's not a simple 0 to N for loop.) If there had been any overhead, C++ probably would not have become as widely adopted as it is now.
Also, these techniques should be possible in C++ through templates. If you want safety, then don't use naked arrays. I realize that's not any help for code you inherit, but good design can avoid these problems.
One of the design goals of C++ was to add OO capabilities to C without adding any execution or space overhead. Fixing the "safety problem," as you call it, would involve an increase in execution time. When what you want conflicts with one of the design goals, then you're probably using the wrong tool.
Bull. In The Design and Evolution of C++, Stroustrup clearly lays out how he decided which features should be included. He was sensitive to feature creep, and rejected far more ideas than he accepted. Ideas he did accept had to be useful to a majority of programmers, feasible to implement and feasible to teach.
And frankly, C is not hard if you have enough understanding of a computer. It is widely considered a small language that does its intended job well.
I'm curious why you think multiple inheritence in C++ is more trouble than it's worth.
As far as operator overloading is concerned, the intent was to provide the conceptual parallelism you explained. In D&E, he talks about C++ users asking for the capability for things like matrix addition. Using << and >> for stream input and output was an afterthought. Further, I don't think it was leveraging the C compiler that precluded him from overloading operators other than what were already in C. He easily could have supported new operators, as Cfront was not just a preprocessor, it was a full compiler that happened to compile down to C. Since I've never read anywhere (either in interviews, D&E, or TC++PL) why he chose to not allow arbitrary operators, I assume it was because he didn't feel they were necessary. I know that D&E has discussion of an exponent operator, which was eventually ruled out.
For students who want to actually do research in computer science: They're in the wrong department. The best preparation for graduate work in computer science is an undergraduate degree in mathematics.
False. I am a CS Ph.D. student. I do research in high performance systems. A math degree is not preperation for systems research. There is more - much more - to gradute CS work than theory.
(k) "Advertisement" means any public communication made by or on behalf of a lawyer or law firm about a lawyer or law firm, or about a lawyer's or law firm's services.
I think it's reasonable to call a lawyer's blog a public communication made by that lawyer about that lawyer. And that fits the proposed definition of advertisement. That seems to be a broad definition of advertising.
The article mentions proto-primates, not what we would call primates today. So for those snakes and mammals, they might have had a stronger predator/prey relationship than what we call primates. The current relationship you bring up may be a result of primate evolution to be able to detect snakes better.
I'm not arguing the theory is correct, just that it is self-consistent and sounds plausible.
You may be interested in a paper from PLDI of this year, Shared Memory Programming for Large Scale Machines. They implemented UPC on BlueGene/L, and the paper explains the infrastructure they developed to do that. However, it's not about how to program on BlueGene/L.
I think the poster implied that the Olympics are not for people whose sole exemplary attribute is high twich response. A sprinter, for example, must have fast twitch response, but they also must be excellent athletes. Being first off the block isn't enough to win, you also have to be able to run fast.
it's not a trivial issue, but coming out with a blanket statement that 'shared memory scales and message passing doesn't' is what is naive.
That would be naive, so it's a good thing I did not say that. My point all along has been about granularity of exploitable parallelism, and that shared memory parallelism allows you to exploit a finer granularity. I said nothing about scalability. It's not always true, but in general, the finer the granularity you try to exploit, the less scalability you're going to get because there's less parallelism to exploit.
I still think you're missing my point about granularity of parallelism. Any problem that is coarse-grain enough to be implemented with message passing should be. But some problems are too fine-grain to be implemented with message passing and inherently won't scale beyond a single node.
In my world, "message passing" implies that you're going to scale to multiple nodes. But my point still stands even on a single node. Calling it simply an "implementation issue" is naive, because I'm unaware of any languages, libraries or compilers that are sophisticated enough to completely remove the overhead of passing messages.
The algorithm may fair poorly when given only 2 or 3 threads in parallel or with less than say 10000 things that need to be done, but really that isn't much of a parallel problem at all.
Yes, there is a real reason. Sometimes it's inherent in the algorithm that the amount of data that must be shared is impractical to send using messages. Parallelization does not come for free; there are communication costs. If the communication costs are greater than the benefit you get from doing the computation in parallel, then you get no benefit from parallelization. Message passing will always have more overhead than shared memory multithreading. Hence, shared memory multithreading allows you to exploit finer grain parallelism than message passing.
Your point that message passing is generally a cleaner design choice is valid, but it's not always a practical option.
I know lagging behind the synchronization of caches between 16 cpu-s is fun but wouldn't it be way more efficient to have a forked application instead that just send messages across to synchronize the data you really need to share ?
Not always. If the level of parallelism is very fine, then the synchronization costs would overwhelm any gains from running in parallel. I really don't understand your overall point, either. Running a scalable multithreaded app over as many CPUs as possible is exactly what you want to do.
Slashdot Mirror
By lifespan, I don't mean when production starts to when production ends. I mean from when PS3s go on sale to when major developers cease developing and marketing games for the PS3, and there is a PS3 successor.
Sony is hoping for a 10 year lifetime on the PS3 (sorry, can't cite a source, it's a random tidbit I read somewhere), so development methods for it might actually have time to become mature.
That's because the Linux kernel and everything compiled for it don't use the SPEs (the Cell vector cores), and it's the SPEs that make the Cell processor powerful. Nor can they, really. Most of what the kernel and other applications do will not benefit from a vector processor. However, graphics and scientific computing will.
Stroustrup's original goal was for a language that allowed OO programming and was still suitable for serious systems programming. I think he makes that clear in The Design and Evolution of C++. And are you aware that the original name was, in fact, C with Classes?
I like functional programming, but it's been around for a long, long time. The only language older than LISP is Fortran. I think if the "functional programming revolution" was going to happen, it would have already happened.
No, I don't think it's telling that Stroustrup finds it useful to explain how he decided what did and did not get into the language. The mere fact that people shout about something doesn't mean that they have a valid complaint.
As far as C goes, yes, you can write obtuse code with non-obvious semantics. But that's true of any useful language. Much of what you blame on C is a result of the fact that it's basically a high level assembler. The fact that manipulating hardware can be confusing is not the fault of C.
Simply using a std::vector won't do the job. But I think it's reasonable to implement what you described with templates with checks at compile time - but I'm not sure as I have not done it.
Again, Stroustrup was concerned with runtime effeciency. C++ was intended to be a systems programming language with high level abstraction mechanisms. It was not intended to be a language with runtime checks for correctness. All of the overheads you mention are real and I won't disagree with them. I think that there are many domains where checked languages are appropriate and desirable. Since what you want runs contrary to the original design goals of the language, then I just can't consider your complaints valid.
That is interesting, and thanks for the pointer to Spec# (I'm re-reading the tech report on Singularity for my quals, so it's relevant to me at the moment). But Stroustrup makes clear in D&E that any overhead was unacceptable. While checks can be done at compile time, not all of it can. (I think that most difficult to spot errors are going to happen in places where it's not a simple 0 to N for loop.) If there had been any overhead, C++ probably would not have become as widely adopted as it is now.
Also, these techniques should be possible in C++ through templates. If you want safety, then don't use naked arrays. I realize that's not any help for code you inherit, but good design can avoid these problems.
One of the design goals of C++ was to add OO capabilities to C without adding any execution or space overhead. Fixing the "safety problem," as you call it, would involve an increase in execution time. When what you want conflicts with one of the design goals, then you're probably using the wrong tool.
Bull. In The Design and Evolution of C++, Stroustrup clearly lays out how he decided which features should be included. He was sensitive to feature creep, and rejected far more ideas than he accepted. Ideas he did accept had to be useful to a majority of programmers, feasible to implement and feasible to teach.
And frankly, C is not hard if you have enough understanding of a computer. It is widely considered a small language that does its intended job well.
I'm curious why you think multiple inheritence in C++ is more trouble than it's worth.
As far as operator overloading is concerned, the intent was to provide the conceptual parallelism you explained. In D&E, he talks about C++ users asking for the capability for things like matrix addition. Using << and >> for stream input and output was an afterthought. Further, I don't think it was leveraging the C compiler that precluded him from overloading operators other than what were already in C. He easily could have supported new operators, as Cfront was not just a preprocessor, it was a full compiler that happened to compile down to C. Since I've never read anywhere (either in interviews, D&E, or TC++PL) why he chose to not allow arbitrary operators, I assume it was because he didn't feel they were necessary. I know that D&E has discussion of an exponent operator, which was eventually ruled out.
I think that the concept of perfection has no meaning in the context of something subjective like how good a videogame is, or quality of art.
For students who want to actually do research in computer science: They're in the wrong department. The best preparation for graduate work in computer science is an undergraduate degree in mathematics.
False. I am a CS Ph.D. student. I do research in high performance systems. A math degree is not preperation for systems research. There is more - much more - to gradute CS work than theory.
I think it's reasonable to call a lawyer's blog a public communication made by that lawyer about that lawyer. And that fits the proposed definition of advertisement. That seems to be a broad definition of advertising.
Wait, what? Who in the establishment feels threatened by MMORPGs?
The article mentions proto-primates, not what we would call primates today. So for those snakes and mammals, they might have had a stronger predator/prey relationship than what we call primates. The current relationship you bring up may be a result of primate evolution to be able to detect snakes better.
I'm not arguing the theory is correct, just that it is self-consistent and sounds plausible.
I'm surprised no one has asked this. What about these experiments requires simulation? Why couldn't they just use physical objects?
You may be interested in a paper from PLDI of this year, Shared Memory Programming for Large Scale Machines. They implemented UPC on BlueGene/L, and the paper explains the infrastructure they developed to do that. However, it's not about how to program on BlueGene/L.
I think the poster implied that the Olympics are not for people whose sole exemplary attribute is high twich response. A sprinter, for example, must have fast twitch response, but they also must be excellent athletes. Being first off the block isn't enough to win, you also have to be able to run fast.
it's not a trivial issue, but coming out with a blanket statement that 'shared memory scales and message passing doesn't' is what is naive.
That would be naive, so it's a good thing I did not say that. My point all along has been about granularity of exploitable parallelism, and that shared memory parallelism allows you to exploit a finer granularity. I said nothing about scalability. It's not always true, but in general, the finer the granularity you try to exploit, the less scalability you're going to get because there's less parallelism to exploit.
I still think you're missing my point about granularity of parallelism. Any problem that is coarse-grain enough to be implemented with message passing should be. But some problems are too fine-grain to be implemented with message passing and inherently won't scale beyond a single node.
In my world, "message passing" implies that you're going to scale to multiple nodes. But my point still stands even on a single node. Calling it simply an "implementation issue" is naive, because I'm unaware of any languages, libraries or compilers that are sophisticated enough to completely remove the overhead of passing messages.
The algorithm may fair poorly when given only 2 or 3 threads in parallel or with less than say 10000 things that need to be done, but really that isn't much of a parallel problem at all.
Bingo. It has to do with the granularity of parallelism. You can take a look at this paper written by people I work with, Multigrain Parallel Delaunay Mesh Generation: Challenges and Opportunities for Multithreaded Architectures. But understanding why is simple: if the cost of communication overwhelms the gain from doing the computation in parallel, then it doesn't scale.
Yes, there is a real reason. Sometimes it's inherent in the algorithm that the amount of data that must be shared is impractical to send using messages. Parallelization does not come for free; there are communication costs. If the communication costs are greater than the benefit you get from doing the computation in parallel, then you get no benefit from parallelization. Message passing will always have more overhead than shared memory multithreading. Hence, shared memory multithreading allows you to exploit finer grain parallelism than message passing.
Your point that message passing is generally a cleaner design choice is valid, but it's not always a practical option.
I know lagging behind the synchronization of caches between 16 cpu-s is fun but wouldn't it be way more efficient to have a forked application instead that just send messages across to synchronize the data you really need to share ?
Not always. If the level of parallelism is very fine, then the synchronization costs would overwhelm any gains from running in parallel. I really don't understand your overall point, either. Running a scalable multithreaded app over as many CPUs as possible is exactly what you want to do.