3 ms·
> At the same time, higher-level languages sometimes can almost encourage the blindness to the real world model of computation, the execution implications be da
by titzer 2y ago
> At the same time, higher-level languages sometimes can almost encourage the blindness to the real world model of computation, the execution implications be damned. In such languages you will encounter way more people who will write O(n^3) algorithm and will fight you tooth and nail to keep it that way because they have zero understanding of the fundamentals, wasting the heroic effort by the runtime/compiler to keep it running acceptably well.
I would say this tracks. I spent some time doing research on JVMs and largely found that, for example, the Java community largely values building OO abstractions around program logic and structuring things in ways that generally require more runtime logic and safety checks. For example, Java generics are erased and replaced with casts in the bytecode. Those checks the JVM has to blindly perform in the interpreter and any lower compiler tiers that don't inline. Only when you get to opt tiers does the compiler start to inline enough to see enough context to be able to statically eliminate these checks.
Of course Java hides these checks because they should never fail, so it's easy to forget they are there. As an API designer and as a budding library writer, Java programmers learn to use these abstractions, like the nicety of generics, in order to make things more general and usable. That's the higher priority, and when the decision criteria comes down to performance versus reuse, programmers choose reuse all the time.
- cogman10 2y ago> that generally require more runtime logic and safety checks. These safety checks and runtime logic are a constant factor in the performance of a given java application. Further, they are mostly miniscule compared to other things you are paying for by using java. The class check requires loading the object from main memory/cpu cache but the actual check is a single cycle cmp check. Considering the fact that that object will then be immediately used by the following code (hence warm in cache) the price really isn't comparable to the already existing overhead of reaching down into ram to fetch it. I won't say there aren't algorithms that will suffer, particularly if you are doing really heavy data crunching that extra check can be somewhat murder. However, in the very grand scheme of things, it's nothing compared to all the memory loading that goes on in a typical java application. That is to say, the extra class cast on an `ArrayList<Point>` is nothing compared to the cost of the memory lookups when you do int sum = 0; for (var point : points) { sum += point.x + point.y + point.z }
- deleted 2y ago[deleted]
- neonsunset 2y ago> The class check requires loading the object from main memory/cpu cache but the actual check is a single cycle cmp check. Only a guard or, possibly, a final class type-check (at least it's the case for sealed classes or exact type comparisons in .NET). For anything else this will be more involved due to inheritance. Obviously for any length above ~3 this won't dominate but JVM type system defaults don't make all this any easier.
- wbl 2y agoI'm not an expert but I think that the compiler requires the exact class on insertion so at use it's just a check.