61–70 of 120 posts
Earlier quoted context omitted.
can you explain a little further ?
I think it's easier to read the code: https://github.com/logicchains/LPATHBench/blob/master/jv.jav... Instead of a vector of node classes, there's a static final int[][] nodes; Which is used in a similar manner to a vector of node classes, but due to containing primitives (ints) is unboxed.
C++ wins again. There's really no competition.
Meh. Only if you value performance above correctness and maintainability. Besides, C wasn't tested. C would win if it were, I'm pretty sure.
Earlier quoted context omitted.
I don't think this improvement is really fair though. Everybody heard the same thing as you did : arraylist are ok performance wise. The optimisation of using arrays and static global variables and remove use of any object isn't something that leads to readable code in the long run, nor is it the code your regularely see in everyday software. You should include both your old java code with the new one. Call your vers…
It is idiomatic in highly performance-sensitive Java code though. Hopefully it won't be necessary in Java 9 or 10 when unboxing support is brought in. I've added a note regarding the change, but I'm off to bed in a moment (AEST timezone). I'll separate the Java versions tomorrow.
Earlier quoted context omitted.
>> OpenJDK is indeed a "steaming pile of crap" > Just to clarify, it performed as well as the Oracle JVM on x86. Its poor performance on ARM is just due to its lack of JIT compilation. Understood. Admittedly, I'm a system administrator first, developer second. However, my experience has shown that Sun/Oracle JVM usually out performs OpenJDK. Even in development, on the Java teams I've had to support, OpenJDK is never…
>However, my experience has shown that Sun/Oracle JVM usually out performs OpenJDK. Even in development Your experience seems to be filtered through your misconceptions. It is the same code base.
Edit: I tested the C++ version on my 5-year-old i7, with an even older compiler (just had to modify the code to not use C++11 features), and with the max optimisation level, it produces a result of 1465ms - which is pretty damn amazing, considering that this is a 16-year-old compiler generating 32-bit code and the most recent CPU it had knowledge of was the Pentium Pro (P6)! I'm convinced that an Asm version could be <1s though, so there's still plenty of room for improvement.
> Functional code in Haskell/OCaml can be faster than imperative code using iorefs. IORefs involve locking. They are bad performance-wise. An algorithm like this should be done either fully functionaly without any mutation at all or in ST.
Poking through GHC's runtime source, I see a writer barrier but no locking -- did I miss something?
I'm not really sure what this data means because amd64 and ARMv7 are ISAs. For instance, you could make a very deep and superscalar ARMv7 chip that blows a typical amd64 out of the water if you sacrifice size and power. Is the intent simply to show that some language backends are not optimized? Otherwise, without something like "These two chips and clock-for-clock or watt-for-watt it looks like this" it seems meaning…
It's not meant to compare AMD64 and ARMv7 architectures, it's meant to compare the performance of various language compilers/runtimes on two common AMD64 and ARMv7 chips.
Earlier quoted context omitted.
Except it's really hard to benchmark on ARMv8 since non-Apple hardware is expensive.
> hard to benchmark on ARMv8 since non-Apple hardware is expensive. If Android will do - Cortex-A53 smartphones like the Huawei Ascend Y550 cost 120€ nowdays in Europe (about 4x the price of a Raspberry Pi).
- Far too little memory (2GB vs 16/32GB+)
- Slow flash vs SATA disks
- The "zoo" of u-boot/proprietary kernel crap, instead of UEFI, ACPI and standard upstream kernels
- Nonsense like locked bootloaders (Nexus 9 disables HYP mode in the bootloader!!!)
Earlier quoted context omitted.
>> OpenJDK is indeed a "steaming pile of crap" > Just to clarify, it performed as well as the Oracle JVM on x86. Its poor performance on ARM is just due to its lack of JIT compilation. Understood. Admittedly, I'm a system administrator first, developer second. However, my experience has shown that Sun/Oracle JVM usually out performs OpenJDK. Even in development, on the Java teams I've had to support, OpenJDK is never…
>However, my experience has shown that Sun/Oracle JVM usually out performs OpenJDK. Even in development Your experience seems to be filtered through your misconceptions. It is the same code base.
I am not a Java developer. I am a system administrator.
I wonder how much of the difference we're seeing between various languages is the quality of the code their compilers generate for various backends and how much is due to the different languages benefiting more from architectural differences between the two chips.
I imagine that languages that generate code with more indirection are going to excersize the prefetcher and branch predictor of the core they're running on much more than languages that generate code with simpler control flows. Both the A9 and the Nehalem cores are out of order but the Nehalem has a much, much more sophisticated set of facilities for that. I predict that if you were to re-run the benchmarks on an iPhone 5S you'd see much less of a difference between the various ARM times. And if you were to run it on a cheap Android phone with A7 or A53 cores you'd see a much larger difference.