8-Way Linux Distribution Benchmarks On The Intel Core i9 9900K - One Distro Wins 67% Of The Time

[dxxvi]

Artix Linux... No systemd. See if your compile optimized systemd can defeat runit...

Does Artix Linux use its own package repositories like Manjaro? Arco uses Arch Linux's repositories.

[M@yeulC]

My comment was in general that I don’t see a point in doing Octave benchmarks at all, as someone who cares even just a litte bit about performance in scientific computing would never consider Octave in the first place. Even if you run Octave on a dual Xeon machine with terabytes of RAM, Julia on a Raspberry Pie will burn it to the ground with ease. Here are some numbers to compare: https://julialang.org/benchmarks

Would really be rad if you’re interested in including Julia benchmarks! Here are some, for example:

https://github.com/JuliaCI/BaseBenchmarks.jl

https://github.com/JuliaCI/BenchmarkTools.jl

I'm rather doubtful of that statement. Octave can be extremely fast when working with properly vectorized code. A recursive algorithm such as the one on that page is rather a worst-case scenario.
Most of the time you use the builtin functions, anyway. Most of these have native and optimized implementations. Then you run the data trough vector operations, that are performed by BLAS-compatible libraries. I'm not sure you can beat that performance-wise.

On the other hand, sure, basic looping, branching and function calling is quite slow in Octave (though there was a LLVM-based JIT in the works). But I use it a lot, and I've never been disappointed by its performance.

Vectorizing can be quite hard for newcomers, though: I once helped a guy speed up his materials simulation from a couple days of runtime to a couple seconds. That was with MATLAB, mind you (which is faster than Octave in the aforementioned worst-cases, without JIT at least).

[coder]

According to Tiobe, Julia is already #43 while just having reached v1.0 – Octave is not even mentioned while it exists for how many years?
https://www.tiobe.com/tiobe-index//

Octave == MATLAB (i.e. #11, up from #13 last year).

[Zyklon]

I think there are still way more Octave users than Julia. I occasionally use Octave, but not enough to be worth investing time in learning something else. The only other sort of comparable thing I find myself using is numpy.

I'm not arguing against Julia benchmarks - particularly if it's good at scaling to multiple cores. I'm just saying that Octave is hardly as irrelevant as you seem to imply.

According to Tiobe, Julia is already #43 while just having reached v1.0 – Octave is not even mentioned while it exists for how many years?

https://www.tiobe.com/tiobe-index//

Julia is the future scripting language, as it can replace Matlab, Python, R, sh, bash, *sh and several others, like Octave, Scilab, Sage etc. Just like Rust will replace a lot of C, C++, Java etc. I always hated the fact that there are so many languages – normal programmers are never able to really utilize them. Take shell scripting as an example, this is pure crap. Being able to reduce this number significantly will allow programmers to get better. Compared with the enormous power of Julia, these are the reasons why this language is so important.

[Artemis3]

I suggest that Manjaro should be replaced by ArcoLinux which is closer to ArchLinux, I think.

Artix Linux... No systemd. See if your compile optimized systemd can defeat runit...

[dxxvi]

I suggest that Manjaro should be replaced by ArcoLinux which is closer to ArchLinux, I think.

[Michael]

Are those kernel parameters? Doesn't the Kernel disable certain mitigations based on runtime detection of the CPU model? I thought this was used by Ryzen, to avoid certain mitigations needed for Intel CPUs. If that's true, then only the latest kernels will know about the i9 and its security capabilities.

So, rather than kernel parameters, isn't there something in sysfs to query about which mitigations are active? Or maybe that's what you're doing. Forgive my ignorance, but I'm probably not the only one who hasn't followed this too closely.

Thanks for your patience.

PTS is querying the sysfs data and reporting that which does indicate what is actually applied by default.

[coder]

All the mitigations for Spectre/Meltdown are shown on the automated system hardware/software table within the article.

Are those kernel parameters? Doesn't the Kernel disable certain mitigations based on runtime detection of the CPU model? I thought this was used by Ryzen, to avoid certain mitigations needed for Intel CPUs. If that's true, then only the latest kernels will know about the i9 and its security capabilities.

So, rather than kernel parameters, isn't there something in sysfs to query about which mitigations are active? Or maybe that's what you're doing. Forgive my ignorance, but I'm probably not the only one who hasn't followed this too closely.

Thanks for your patience.

[Michael]

It would be helpful if you could also summarize the Specter/Meltdown status of these Kernels. My hunch is that Clear pulls such a big lead on I/O because is circumventing certain software workarounds that the Coffee Lake Refresh CPUs implement in hardware.

Generally speaking, I/O is least affected by things like compiler optimizations.

All the mitigations for Spectre/Meltdown are shown on the automated system hardware/software table within the article.

[coder]

It is used by at least a number of some data centers / cloud, IoT, and other environments but exactly where it's used doesn't seem to be widely published.

It would be helpful if you could also summarize the Specter/Meltdown status of these Kernels. My hunch is that Clear pulls such a big lead on I/O because is circumventing certain software workarounds that the Coffee Lake Refresh CPUs implement in hardware.

Generally speaking, I/O is least affected by things like compiler optimizations.