[geocar]

> Can you point to these Stac-M3 results and maybe at least mention that language? I wasn't able to find it.

That makes sense, since your background isn't in high performance computing and you can't use google:

https://stacresearch.com/m3

The first item on the list is written in an interpreted language.

> This is not just an opinion, it's scientific and objective fact.

I've just demonstrated two counterexamples, so it's clearly not "scientific and objective fact". Indeed I've never met anyone who even thought Rust would outperform an experienced C programmer in programmer speed, program runtime, and low program size.

[ernst_klim]

>The first item on the list is written in an interpreted language.

Could I see the code? Because I'm pretty sure you can't write a fast numeric code without the knowledge of which type you will get on input. That's why fortran still rocks and we do nat have anything beyond fortran, c and c++ in the field of computation.

[geocar]

> Because I'm pretty sure you can't write a fast numeric code without the knowledge of which type you will get on input. That's why fortran still rocks and we do nat have anything beyond fortran, c and c++ in the field of computation.

You're not far off.

The first trick is that even though `x` can have any type, `x[4]` and `x[5]` must have the same type. This kind of array whilst uncommon in Python is extremely common in array languages. Array languages tend to have a lot of vector operators (and so therefore are very competitive users of the AVS512 instruction set) which tend to be very fast. Programmers of array languages also tend to avoid things like loops and branches -- indeed you might enjoy http://nsl.com/ if you want to expand your mind a bit on that point.

The second trick is that an interpreter can be made very small. If you can get your entire program and the interpreter into L1 then you do not stall the CPU while your program fetches various parts of itself from memory. This is a trick languages like Fortran and C and C++ don't miss per-se, a very experienced programmer can usually identify the hotspots and optimise the hotpath for these things, but it is very time consuming to do this when your entire program is the hotpath!

[geocar]

That should have been AVX512. I blame autocomplete for the typo and myself for missing it.

[hota_mazi]

That's the first link I found and it says nothing about a benchmark, what's being benchmarked, what languages were used and what the timings were.

Do you actually have anything to show to back up your claim? Anything at all?

[geocar]

> That's the first link I found and it says nothing about a benchmark

Except the first paragraph:

The STAC-M3 Benchmark suite is the industry standard for testing solutions that enable high-speed analytics on time series data, such as tick-by-tick market data (aka "tick database" stacks).

I'm not going to bother any further with such an obvious troll.

Good luck dude. Wish you the best.

[hota_mazi]

So you still can't name the language that won these benchmarks and which other languages it ran against?

Because they're not on the page, so I can only conclude you made this up.