[avyjit]

When you refer to modern hardware with vectorization, are you saying perl beats software that makes use of vector instructions? If so wow! Afaik perl is a plain old interpreted language with no JIT, what makes it so fast? I had an idea of perl as in the same performance category as Python, Ruby and friends.

[cogman10]

My assumption (and I could be wrong) is that whenever you do something that's ultimately CPU intense, perl dives into C code. The sort of stuff you do with perl tends to be a lot of string manipulation and it turns out perl is pretty hyper optimized for that sort of workload.

Other languages could do the same, but often they have a few more layers before they start running that C code.

I'd be curious to know if the perl grammar also somehow lends itself to being fairly optimizable for it's interpreter.

[jandrese]

Perl does a kind of half JIT when you start a script. It doesn't compile fully down to native machine code, but it does parse and lex the script to build an internal representation. The code is then interpreted, but since it doesn't have to parse each line again it runs very fast and also you can interpret code on the fly in a variable so you get the best of both worlds.

[int_19h]

This has been the usual way to implement interpreted languages for decades; Perl isn't special in that regard. JIT generally refers to generation and execution of native code specifically.

[csdvrx]

> Afaik perl is a plain old interpreted language with no JIT, what makes it so fast?

IDK. I didn't waste time checking why.

My guess is that due to the much smaller code size, it reaches a sweetpoint where it fits nicely in the L1 or L2 cache.

But it's just a hunch, I couldn't prove it.

[kstrauser]

Perl likely spends a lot more time in C than a lot of other bytecode-compiled languages like Python.

  while(<STDIN>) {
   print $_;
  }

isn't doing much of its work at the top level.