Forgot your password?
typodupeerror

Comment: Re:Just Pick One and Learn it Well - or NOT (Score 1) 817

by Totally_Lost (#14331218) Attached to: Learning Java or C# as a Next Language?
One of the problems of rapidly increasing complexity of applications, particularly Java/C#/C++ and other object oriented languages, is that performance is critically destroyed by design, and it's nearly impossible to recover it without re-writing the core of the application procedurally.

The problem here is that small dynamically allocated objects with heavy pointer threading flush even large caches quickly and yeild very low locality combined with very low efficiency of cache line memory faults ... small amount of active useful data per cache line, and high overhead in data structures and useless data faulted in. This quickly applies at the page level as well, as locality remain poor between pages of bloated applications working set.

CPU performance scales, even L1/L2 performance scales reasonably well, but raw memory perforance is two orders of magnitude slower than processors and quickly becoming three orders of magnitude slower. It's nearly impossible to constrain page level working sets of OO programs to scale performance.

When more than 20% of your memory hits fault to raw memory, performance just crawls, and a faster machine, with lots more raw memory doesn't help, ... in fact, just makes it worse.

Direct mapped caches, and small set associate caches do not work well with today's OO programming ... needed are very large fully associated caches, and those are not cheap to build.

It's time to realize that for the last 5-10 years memory performace hasn't hardly (in comparison) improved at all ... and it's past time to start looking at programming tools that optimize performance by design, not destroy it.

What good is a 4GHz processor, that runs at 100mHz memory speeds when it's all said and done because of poor cache line usage for every word or two referenced.

COBOL is for morons. -- E.W. Dijkstra

Working...