mar wrote: ↑Tue Nov 27, 2018 3:20 pm
If what you say was true, then these languages (I mean C# and Java) would run as fast as native code. Except for some synthetic benchmarks, this is clearly not the case.
Your logic isnt very sound. The optimizer isnt as good, so the programmer has to make up for it, which does not lead to the conclusion "would run as fast" - leads to the conclusion "might have to do it differently" .. but obviously zero benchmarks accept "doing it differently."
There have been studies (by the ACM) that actually tackle programmers being allowed to do it differently. The one I had read years ago, the result of that study was that the #1 factor in code performance was the programmers level of experience, not the language or compiler. Fit perfectly with what I already figured.
I wholly embarrassed a language bigot once after he showed me a VC98 vs VB98 comparison, a simple file processor that read one byte at a time, by typing 10 contiguous characters into his VB6 code, removing none, and then it was actually just barely beating the C code he was trying to prove a point with.
He was both very disappointed and amazed. Knowledge. I knew that VB6 defaulted to no i/o buffering, and that his C standard library always had a generous buffer of at least 512 bytes (a common disk sector size at the time.)
You can imagine how slow that VB6 code was without any i/o buffering. The 10 characters I added were "len = 4096", an addition that simply added a buffer size to the Open statement in VB6. He then played with optimization levels for the C version, and the C code then was ahead again, but this time by not very much at all.
You get the drift, yes? He was speculating that because his C code was well optimized, that his simple/direct translation would lead to "also well optimized" but... his speculation was wrong. In this case, "doing it differently" wasnt very much different, but I could have also manually added a buffer implementation that didnt use VB6's built in support for buffering and the effect would have been exactly the same, while the code being very much different.
mar wrote: ↑Tue Nov 27, 2018 3:20 pm
I also doubt that you get more than a couple of % by using whole program optimization (you can always put stuff in the headers, this is implied by using templates anyway so the compiler knows about what these functions).
Surely you have functions where a parameter, given as a constant (from an enum of piece types for example), decides the functions code path. With whole program optimization, the conditional on that function parameter is eliminated at compile time, and the now heavily reduced function is either inlined or multiple versions of the function are thus generated in the linked object modules.
If you are worried about bounds checking then surely you should be at least as worried about all the unnecessary conditionals in your program that arent optimized away across function boundaries.
This lack of whole program optimization absolutely REQUIRES you to "do it differently" to get the same performance as when aggressively taking advantage of it. The key is that taking advantage of it is exactly "working with the compiler" instead of against it. Doesnt matter what language or compiler you are using, the *only* way to get good efficiency is to work *with* the compiler.
mar wrote: ↑Tue Nov 27, 2018 3:20 pm
The problem is that arrays in C# or Java are objects, this is both for safety and it simplifies languages design, but the compiler no matter how good can't do much about it
You say objects but I hope you mean reference types.... The inaccuracies in your word usage is very hard to get over. Not going to draw any conclusions from it yet, but its leading to the conclusion that you dont really know much about any c# implementation (and I guess OOP in general) at all.
Integers are objects but you express no worries about integer performance. The fact that integers are objects only creates performance issues when boxing and unboxing them.
What matters is that you know that integers can be used just as efficiently as in other languages in spite of them being objects, and that you know boxing and unboxing are the expensive bits, and thus you can avoid them, yes?
The word you were looking for was 'references'
You didnt answer this question:
WHAT DID YOU DO BEFORE YOUR C COMPILER WAS ANY GOOD?
Like, 1998 compiler terrible? What did you do?
Did you throw up your hands and was the proud producer of terribly performing programs, or did you learn to work with the compiler and eventually managed to coerce efficient binaries out of the compiler in spite of it being far worse at optimizing than any C# compiler ever was?
Seriously, before C compilers optimized so well for you, WHAT DID YOU DO?
