titles, titles, tiles, tyres, troubles, tomatoes, traction, whyest thou a title thee demands
I don't see that recursion or heavily nested code is any intrinsic barrier to compilation. The guaranteed killer is eval( ), although idiosyncratic programming styles are likely to mess it up, so that's my functional stuff down the toilet...
@jlocke: the issue of garbage collection and managed languages etc is an interesting one, but you oversimplify. One language can do a new( ) faster than another by using various tricks and by ignoring amortised costs, such as the GC sweep -- compacting GC'ers can do an allocation in a single pointer-bump, but the sweep phase is another matter.
> Another problem is that you cannot have structure arrays and nested structures. This can easily lead to bad cache usage patterns and consequential performance losses. In C++ you have all of that and also stack-allocated variables of any type. That means the memory you will access soon probably is already in the cache. Extremely fast.
Whether this leads to a slowdown depends on access patterns rather than layout patterns, although certainly you would expect that funny layouts lead to funny access patterns which lead to poor performance, it's not a given. Also there are usually tricks you can pull such as flattening arrays. But rather critically, Java is not tied to the JVM. If you wish to compile Java directly to the native machine then do so.
Saying one language is better than another is pretty meaningless, it depends on intended use. If the car better than an elephant? It depends on whether you're going to the shops in the UK, or punting tree trunks around in an Indonesian forest. And manually handling memory efficiently and correctly, that gets tremendously difficult as the code grows.
And in any event IME the programmer's skill and knowledge seems to be the overriding factor in program efficiency. I really want to emphasise that point.
> If you want to get the last 70 % performance out of an Intel or AMD CPU you need to handcode your innermost loops in assembly.
Any justification for this?
> In some cases, this even makes for a 1000% performance improvement.
That's a big claim.
re. GC read the discussion between myself and /sed gawk/ at <http://forums.theregister.co.uk/forum/2/2010/02/17/top_25_programming_errors/#c_699356>.