All statements in any language must resolve to a set of correct machine instructions either by way of a compiler or an interpreter for the given platform. One can test a set of machine instructions to determine if it is the efficient way to accomplish a given task, be it a simple add or to index memory to obtain the details of a set of objects or a set of chars in the representation of string. It can be done, it has been done, and should be done every time there is a substantive change to the grammar of a language.
Yes but what does that have to do with performance?
In case it wasn't clear, my point was that a hypothetical intelligent (human-level or higher) compiler can extract the purpose/behavior of a program from its source code, and generate optimal (or very close to optimal) machine code for the task. I don't see how your reply relates to this point.
Is it then the job of the compiler to write correct code or is it the job of the programmer? This is an interesting question, which is complex and arguable until the proverbial cows come home.
It's the job of both of course. The programmer should write correct source code and the compiler should correctly convert it to another language (e.g. machine code).
But again, I don't see what your reply has to do with the matter at hand (performance differences between languages in practice).
What does have to do with performance is the talent of the compiler / interpreter author, nothing more, nothing less.
I think your statement is strictly speaking true but not useful in practice.
Here's what I mean: strictly speaking, with unlimited intelligence on the compiler's part, the compiler can understand what a program does and rewrite it completely as it wishes to conform to the same behavior. This means any turing-complete language can have the same performance, with a sufficiently intelligent compiler
In practice and in current times, however, a language's features determine how well the state-of-the-art in compilers can optimize a program. To give a very simple example... You don't see compilers inserting statements to free memory in Java programs, even though that would sometimes make them faster than running them with a garbage collector as happens in practice.
What's there trollish in that post? It's just a shortcut to say some evidence is needed for that extraordinary claim, especially considering APL is usually an interpreted language.
> The java runtime doesn't have to because it doesn't allow arbitrary pointers to memory.
True, but it would still have to check the contents of the referenced objects, to ensure they didn't change (if the optimization strategy allows for functions with references to be optimized).
> Yes, Java currently collects runtime statistics so that it knows which calls might benefit from compiling to machine language.
I meant for the specific case of knowing whether to inline a function or not. Collecting metrics for that seems like a big overhead considering the benefit.
> Since the programs are submitted by language advocates and repeatedly revised, I'm guessing none of them have really big obvious time-sinks.
I will definitely compare the C and C++ versions of those problems where they differ a lot, to understand what's happening there. Maybe the problem lies in compiler differences as you said.
I get your point about memory allocation. There's definitely room for improvement in some C libraries, but I think some of them also have separate heaps for big and small objects.
TFA mentions that the way the dice are carried up in the buckets does damage them a bit. It's not a stretch that some of that damage could be self-reinforcing, as in a feedback loop. Potentially ending up at a point where every single dice is biased.
One solution would be to periodically replace all the die, of course.
Exactly, now do it for every single function, automatically determining (by call count and mutability of external references) if it makes sense or not. Now you DO have a runtime.
At compile time, you would make the safety checks to see if a function is safe enough to be optimize (it certainly can't use global variables, unless the contents of those are also to be recorded; changing global variables would be a no-go of course). And it would only be able to call equally safe functions.
I think you're blurring the definition of a runtime a bit. I don't consider inserting trivial wrapper code around a function's contents a real runtime system, but if you want to call it that, go ahead. That's what things like gprof (profiler) do, and it works just fine.
Also, how do you prove that pointers haven't modified the values you depend on without checking each one?
The same way that the runtime would do it. The runtime would also have to check such things (and that's if they dare to apply this optimization to functions accessing foreign objects).
--Inlining code like that (or not) based on runtime statistics.
Is that improvement worth it when you have to constantly gather statistics about every function call? There's two sides to this coin, you know. Does Java implement that?
--Taking code written as single-threaded and throwing multiple threads at it when it determines that two paths don't interact. (This could be done at compile time as well, but could be done more efficiently with code profiling information in memory.)
How would it prove that the two paths don't interact, in a way which can't be done by a compiler? The compiler can also simulate the running of code.
An example would be helpful if you think I'm wrong in this case.
In fact, that may be the point that the C people here are missing. How can C possibly compete with a language that compiles to machine language with more information than the C compiler has at compile time?
That's not the whole picture. Java has more features which add a certain overhead to several operations (function calls, accesses to arrays, type handling and so on).
I accept that having a smart runtime can be helpful in some cases, but it's not like you can't make such a runtime for C either. The fact is that so far C's performance is great without one.
Look at some of those results (The best code submitted by expert programmers for each language)--Java and C are always in the top few, C is almost always a few ticks quicker, but virtually tied.
I looked, and it's a bit weird that the results for C and C++ often differ by a lot (which makes me think the programs are not that optimized, as for small programs like that it should be trivial to make C and C++ as fast as each other).
I assume "elapsed secs" is the most relevant performance statistic.
Still, either C or C++ are always faster than Java, and in most cases much faster as you can see in these comparison pages:
I see a lot of problems for which C/C++ are 2 or 3 times faster than Java.
By the way, it's worth noting that some of these benchmarks do little memory handling and are pretty numerical code which uses few language features. In these cases compiler quality should make most of the difference in results, so Java should fare quite well there.
As long as the dice are well built, yes. Some other guy posted a link to a video of a professional dice maker saying even a 1/1000th of an inch difference in size between the faces can cause significant bias.
It would be trivial to do it in C actually... Just put wrapper code at the entry and exit point of the function to insert the arguments and result into a small hash table. Done, without a runtime.
Please explain how the same function with parameters "1, 2, 3" returns one thing one day, and one thing in the other (assuming it has no side effects or access global/static variables).
This whole thread screams that C programmers spend far too much time thinking about raw execution speed, and far too little time thinking about time to market, maintainability, etc.
Really? I thought the thread was about programmers who love other languages claiming they have better performance than C.
It would be the same as if a C programmer claimed that memory management is easier in C than Java.
It can work even with separate compilation. You just need a way to store information about each compiled function somewhere. It would of course be simpler to implement without separate compilation, but that's not a constraint specific to C.
Why is it very difficult to do for C? You can do it incrementally:
- Start by applying the optimization just to functions which only have arguments passed by value (no pointers allowed), don't call any other functions and don't access static/global variables. This already optimizes a number of cases. - After that, apply the optimization to functions which follow the previous rules but now allowing them to call other functions in the same file (which also follow the same rules). - After that, account for the separate compilation problem (either not allowing it or saving helpful information about other modules somewhere), which will allow you to optimize functions which call functions in other files.
It's also pretty easy to tell if a C function always causes the same output from the same inputs. Just check if no global/static variables are accessed in the function, and that it only calls functions known to be just as clean.
I may have missed some detail, but I honestly can't see any reason why it would be hard to implement such an optimization in a C compiler.
In Lisp, it is easy to write an assembler, which over time allow the same kind of imperative abstractions as are present in C, thus allowing me to write a program with equal speed as in C.
You can do the same in C, so the only conclusion from your argument is that neither is faster. Which makes the whole challenge useless if we go down that road.
Of course, such a thing could also be implemented in C or Pascal, but requires tremediously more effort.
Again this doesn't say anything about the intrinsic performance of a language.
C (and even assembly) can't realize that the same inputs to a routine always cause the same output, and therefore cache the return value and just return it (not without a lot of buggy, custom code anyway). (I'm not saying Java/C# DO this, they may--I understand they were working on it... But just trying to give you an idea of what CAN be done)
You could also easily implement that in C. Of course it would only apply to purely functional C functions, i.e. ones which behavior only depends on their arguments, and that don't have any side effects. But that restriction would also apply to the Java case.
The near future of gaming is easy to predict... More and more publishers will go bankrupt and/or get consolidated with the big ones. In the past 20 years development costs have been increasing exponentially, while revenue hasn't been increasing as fast. It's easy to tell where that leads to.
The cause is mainly that graphics are getting better and better, which means more and more artists are required to make a game. Polyphony Digital, makers of the Gran Turismo series have said a single artist takes 6 months to make a car model for GT5 (for PS3), whereas the same artist took a month doing so for GT3 and GT4 (for PS2), and just a day in GT and GT2 (for PS1).
This has lead to a lot of bankruptcies and consolidation in the gaming industry, with publishers like EA growing a lot. However, we're now at the point that even these big fish are losing money, with EA full of red ink ever since the current generation of consoles started. Take 2 has been posting losses even with its GTA4 multi-million-units cash cow (which has allegedly cost around $100 million to develop. Just open up google finance and check out these companies earnings, they're consistently dismal in the last few quarters/years.
In recent times, Midway has gone bankrupt, troubled Eidos got bought out by Square-Enix and 3D Realms has gone bankrupt. More will follow, THQ being one of the most troubled in the short term.
About the only big companies making money on gaming these days are Nintendo (which took a cautious approach to graphical capabilites in order to keep development costs manageable), Ubisoft, Epic (which makes a lot of its money from engine licensing), Valve (which has Steam) and of course Activision-Blizzard with the WoW cash cow.
Graphical improvements must be toned down for the gaming industry to be viable. Expect the next generation of consoles to take a Wii-like approach towards hardware power, increasing little over the previous generation. Instead the gaming industry will have to generate real innovation, instead of just more polygons and pixels on the screen.
Slashdot Mirror
Yes but what does that have to do with performance?
In case it wasn't clear, my point was that a hypothetical intelligent (human-level or higher) compiler can extract the purpose/behavior of a program from its source code, and generate optimal (or very close to optimal) machine code for the task. I don't see how your reply relates to this point.
It's the job of both of course. The programmer should write correct source code and the compiler should correctly convert it to another language (e.g. machine code).
But again, I don't see what your reply has to do with the matter at hand (performance differences between languages in practice).
I think your statement is strictly speaking true but not useful in practice.
Here's what I mean: strictly speaking, with unlimited intelligence on the compiler's part, the compiler can understand what a program does and rewrite it completely as it wishes to conform to the same behavior. This means any turing-complete language can have the same performance, with a sufficiently intelligent compiler
In practice and in current times, however, a language's features determine how well the state-of-the-art in compilers can optimize a program. To give a very simple example... You don't see compilers inserting statements to free memory in Java programs, even though that would sometimes make them faster than running them with a garbage collector as happens in practice.
What's there trollish in that post? It's just a shortcut to say some evidence is needed for that extraordinary claim, especially considering APL is usually an interpreted language.
Citation needed.
LTE handsets and PC cards aren't even out yet.
Can you provide the slightest bit of evidence to your claim? Your previous link contradicts what you're saying, you know.
It says:
"Rather, this site will become part of a commercial network scheduled to go live in 2010"
Which means it's still under test.
It's not ready to be used commercially yet though, just part of tests.
Oh, it has also lost Sony $4 + billion, maybe more than $5 billion.
Source: Sony's financial reports in their investor relations page, Games division.
Sony went from 70% market share in the previous generation to around 20% now. That's what's wrong ;)
> The java runtime doesn't have to because it doesn't allow arbitrary pointers to memory.
True, but it would still have to check the contents of the referenced objects, to ensure they didn't change (if the optimization strategy allows for functions with references to be optimized).
> Yes, Java currently collects runtime statistics so that it knows which calls might benefit from compiling to machine language.
I meant for the specific case of knowing whether to inline a function or not. Collecting metrics for that seems like a big overhead considering the benefit.
> Since the programs are submitted by language advocates and repeatedly revised, I'm guessing none of them have really big obvious time-sinks.
I will definitely compare the C and C++ versions of those problems where they differ a lot, to understand what's happening there. Maybe the problem lies in compiler differences as you said.
I get your point about memory allocation. There's definitely room for improvement in some C libraries, but I think some of them also have separate heaps for big and small objects.
TFA mentions that the way the dice are carried up in the buckets does damage them a bit. It's not a stretch that some of that damage could be self-reinforcing, as in a feedback loop. Potentially ending up at a point where every single dice is biased.
One solution would be to periodically replace all the die, of course.
At compile time, you would make the safety checks to see if a function is safe enough to be optimize (it certainly can't use global variables, unless the contents of those are also to be recorded; changing global variables would be a no-go of course). And it would only be able to call equally safe functions.
I think you're blurring the definition of a runtime a bit. I don't consider inserting trivial wrapper code around a function's contents a real runtime system, but if you want to call it that, go ahead. That's what things like gprof (profiler) do, and it works just fine.
The same way that the runtime would do it. The runtime would also have to check such things (and that's if they dare to apply this optimization to functions accessing foreign objects).
Is that improvement worth it when you have to constantly gather statistics about every function call? There's two sides to this coin, you know. Does Java implement that?
How would it prove that the two paths don't interact, in a way which can't be done by a compiler? The compiler can also simulate the running of code.
An example would be helpful if you think I'm wrong in this case.
That's not the whole picture. Java has more features which add a certain overhead to several operations (function calls, accesses to arrays, type handling and so on).
I accept that having a smart runtime can be helpful in some cases, but it's not like you can't make such a runtime for C either. The fact is that so far C's performance is great without one.
I looked, and it's a bit weird that the results for C and C++ often differ by a lot (which makes me think the programs are not that optimized, as for small programs like that it should be trivial to make C and C++ as fast as each other).
I assume "elapsed secs" is the most relevant performance statistic.
Still, either C or C++ are always faster than Java, and in most cases much faster as you can see in these comparison pages:
http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=javasteady&lang2=gpp&box=1
http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=javasteady&lang2=gcc&box=1
I see a lot of problems for which C/C++ are 2 or 3 times faster than Java.
By the way, it's worth noting that some of these benchmarks do little memory handling and are pretty numerical code which uses few language features. In these cases compiler quality should make most of the difference in results, so Java should fare quite well there.
As long as the dice are well built, yes. Some other guy posted a link to a video of a professional dice maker saying even a 1/1000th of an inch difference in size between the faces can cause significant bias.
It would be trivial to do it in C actually... Just put wrapper code at the entry and exit point of the function to insert the arguments and result into a small hash table. Done, without a runtime.
http://en.wikipedia.org/wiki/Hardware_random_number_generator
Please explain how the same function with parameters "1, 2, 3" returns one thing one day, and one thing in the other (assuming it has no side effects or access global/static variables).
Really? I thought the thread was about programmers who love other languages claiming they have better performance than C.
It would be the same as if a C programmer claimed that memory management is easier in C than Java.
It can work even with separate compilation. You just need a way to store information about each compiled function somewhere. It would of course be simpler to implement without separate compilation, but that's not a constraint specific to C.
Why is it very difficult to do for C? You can do it incrementally:
- Start by applying the optimization just to functions which only have arguments passed by value (no pointers allowed), don't call any other functions and don't access static/global variables. This already optimizes a number of cases.
- After that, apply the optimization to functions which follow the previous rules but now allowing them to call other functions in the same file (which also follow the same rules).
- After that, account for the separate compilation problem (either not allowing it or saving helpful information about other modules somewhere), which will allow you to optimize functions which call functions in other files.
Which of these steps would be terribly hard?
It's also pretty easy to tell if a C function always causes the same output from the same inputs. Just check if no global/static variables are accessed in the function, and that it only calls functions known to be just as clean.
I may have missed some detail, but I honestly can't see any reason why it would be hard to implement such an optimization in a C compiler.
You can do the same in C, so the only conclusion from your argument is that neither is faster. Which makes the whole challenge useless if we go down that road.
Again this doesn't say anything about the intrinsic performance of a language.
You could also easily implement that in C. Of course it would only apply to purely functional C functions, i.e. ones which behavior only depends on their arguments, and that don't have any side effects. But that restriction would also apply to the Java case.
I thought landings were more dangerous.
Could you give some examples? Not that I'm doubting you, I'm just curious.
The near future of gaming is easy to predict... More and more publishers will go bankrupt and/or get consolidated with the big ones. In the past 20 years development costs have been increasing exponentially, while revenue hasn't been increasing as fast. It's easy to tell where that leads to.
The cause is mainly that graphics are getting better and better, which means more and more artists are required to make a game. Polyphony Digital, makers of the Gran Turismo series have said a single artist takes 6 months to make a car model for GT5 (for PS3), whereas the same artist took a month doing so for GT3 and GT4 (for PS2), and just a day in GT and GT2 (for PS1).
This has lead to a lot of bankruptcies and consolidation in the gaming industry, with publishers like EA growing a lot. However, we're now at the point that even these big fish are losing money, with EA full of red ink ever since the current generation of consoles started. Take 2 has been posting losses even with its GTA4 multi-million-units cash cow (which has allegedly cost around $100 million to develop. Just open up google finance and check out these companies earnings, they're consistently dismal in the last few quarters/years.
In recent times, Midway has gone bankrupt, troubled Eidos got bought out by Square-Enix and 3D Realms has gone bankrupt. More will follow, THQ being one of the most troubled in the short term.
About the only big companies making money on gaming these days are Nintendo (which took a cautious approach to graphical capabilites in order to keep development costs manageable), Ubisoft, Epic (which makes a lot of its money from engine licensing), Valve (which has Steam) and of course Activision-Blizzard with the WoW cash cow.
Graphical improvements must be toned down for the gaming industry to be viable. Expect the next generation of consoles to take a Wii-like approach towards hardware power, increasing little over the previous generation. Instead the gaming industry will have to generate real innovation, instead of just more polygons and pixels on the screen.
Because if dst is a pointer, sizeof(dst) gives you the size of the pointer, not the size of the object it points to.