[newswasboring]

> Even in the first page of the documentation "No need to vectorize code for performance; devectorized code is fast" is some kind of category error redefinition of how programming languages work in my opinion.

Can you elaborate a bit? I don't really get what you are trying to say.

[th0ma5]

If the code can easily be vectorized then it has the potential to vectorize it incorrectly or there is some automation happening that is hidden. If they're just saying their non-vectorized operations are just as quick, then how quick could true vectorization be. Also, this is how Octave, NumPy, Matlab, R, etc work by making vectorized math operations happen with whole matrices using statements that look like simple non-vector operations. Further, usually when people are having these kinds of issues it's because they started with a non-parallelizable concept of their problem in our trying to redo it... And no amount of magic is going to fix a bad concept of the problem space.

[adgjlsfhk1]

I think the problem here is that there are two very different meanings of "vectorized" at play. The first (and what the Julia docs are talking about here) is the pattern of writing "vector-operations" (i.e. rather than writing a loop, writing an expression that works across an entire array). The second meaning is using SIMD instructions (e.g. AVX2). What the julia docs are trying to say is unlike in languages like Python/R/Matlab where loops have a high overhead do to an interpreter, in Julia, loops are fast because the language is compiled. There are lots of algorithms that are easy to express in an iterative fashion that are pretty much impossible to vectorize efficiently (dataflow analyais/differential equations etc).

The docs here aren't trying to talk about SIMD instructions at all here. (although Julia/LLVM are pretty good at producing SIMD instructions from loops where possible).

[th0ma5]

But no one in science uses Python loops for example, they use NumPy / Jax / Polars etc so that is an unfair and disingenuous comparison.

[adgjlsfhk1]

That's exactly the point. People are changing their coding style to work around the fact that loops in the language are slow.

[th0ma5]

This existed quite a while before Julia, how is it that Julia claims this differentiation then? "We pride ourselves by not using the slow thing you're probably not actually using."

[eesmith]

Because Julia claims to get usability and performance in one language, rather than the two Python needs (Python for the user-facing API, C/C++/Fortran/etc. for performance).

This should also help with optimization, and a larger amount of code can be optimized together, while (C)Python can only optimize up to the Python/C boundary.