News for hackers. Stuff that matters.
Re:Perl 7 is going to be Perl 5.32, mostly by smabie on Wednesday June 24, 2020 @12:40PM (#23630279)
What do you mean by cheap? Also, perl is incredibly inefficient: it's even slower than Python.

Also, how is Perl any less stable than other languages? Are you saying the language doesn't change much or that it doesn't crash?

Re:Perl 7 is going to be Perl 5.32, mostly by cutler on Wednesday June 24, 2020 @01:06PM (#23630729)
On my 4-core i7 Macbook Pro:

    time ./startup_time.pl  0.016s
    time ./startup_time.py  0.295s
Parsing a 20Mb log file with a regex:

    time ./parse_log.pl  0.683s
    time ./parse_log.py  1.534s
For which metric are you claiming Perl is slower than Python?
Re:Perl 7 is going to be Perl 5.32, mostly by smabie on Wednesday June 24, 2020 @03:29PM (#23632743)
Re:Perl 7 is going to be Perl 5.32, mostly by orf on Wednesday June 24, 2020 @01:36PM (#23631159)
Lets see the code? Regex has always been a Perl selling point, and you're just benchmarking the Python Regex library (written in C) against Perl's regex library. That's not a fantastic basis for a comparison.
Re:Perl 7 is going to be Perl 5.32, mostly by cutler on Wednesday June 24, 2020 @02:01PM (#23631524)
Perl 5:

    #!/usr/bin/env perl
    use 5.026;

    open my $fh, '<', 'logs1.txt';
    while (<$fh>) {
      chomp;
      say if /\b\w{15}\b/;
    }
    close $fh;
Python 3.8

    #!/usr/bin/env python

    import re

    with open('logs1.txt', 'r') as fh:
        for line in fh:
            if re.search(r'\b\w{15}\b', line): print(line,   end='')
Why isn't it a fair comparison? The startup time is generic and string parsing is a major feature of, say, web development. I didn't say Perl5 numerics match Python's but even there Python relies on external libs.
Re:Perl 7 is going to be Perl 5.32, mostly by tomku on Wednesday June 24, 2020 @02:46PM (#23632161)
It doesn't account for anywhere near the whole difference, but in a tight loop like that Python's going to be spending a good chunk of its time re-compiling the regex from the raw string literal every iteration. Hoist the regex definition out of the loop like so and it'll probably run about 30% faster:

  #!/usr/bin/env python3

  import re

  with open('logs1.txt', 'r') as fh:
      regex = re.compile(r'\b\w{15}\b')
      for line in fh:
          if regex.search(line): print(line, end='')
Perl almost certainly does this by default for regex literals, and that's a fair advantage for the "kitchen sink" style of language design versus orthogonal features (regex library, raw strings) that Python uses.
Re:Perl 7 is going to be Perl 5.32, mostly by cutler on Wednesday June 24, 2020 @04:55PM (#23633763)
With pre-compiled regex the Python version comes down to 1.483s on my machine which is still considerably slower than Perl. I wrote versions of these using substring `index` instead of a regex and Perl was still the clear winner:

    time ./index.pl  0.258s
    time ./index.py  0.609s
If you factor-in that Python startup time is 0.279s slower than Perl the processing differential comes down to 0.072s.
Re:Perl 7 is going to be Perl 5.32, mostly by dgfitz on Wednesday June 24, 2020 @05:57PM (#23634325)
I'd be curious on your take of my code below, I have python and perl as dead even if you don't print and ignore pythons startup time.
Re:Perl 7 is going to be Perl 5.32, mostly by cutler on Wednesday June 24, 2020 @08:31PM (#23635473)
Well, the two ifs you hedge to qualify Python's parity are pretty damning in themselves, no? Let's stop beating about the bush - if you want to perform a common text-processing job like parsing a log file Perl is hands down faster than Python.
Re:Perl 7 is going to be Perl 5.32, mostly by orf on Wednesday June 24, 2020 @04:37PM (#23633546)
Python caches patterns, you almost never need to re.compile unless you’re a library or have a specific use case involving lots of unique patterns.

The issue here is that pythons regex engine has overhead, and with lots of sequential calls with small strings like that the overhead adds up.

If you batch lines together in chunks you’ll see a huge improvement in speed, but the point is that it’s not “Python vs Perl” it’s “pythons regex engine vs Perl’s regex engine”. Which is about a contrived Perl-biased benchmark if ever there was one.

Re:Perl 7 is going to be Perl 5.32, mostly by dgfitz on Wednesday June 24, 2020 @05:19PM (#23633995)
Running a different test the slowest part of the python script is the startup time, otherwise they're identical:

    [admin@localhost ~]$ time ./test.py
    real 0m0.295s
    user 0m0.158s
    sys 0m0.138s

    [admin@localhost ~]$ time ./test.pl
    real 0m0.164s
    user 0m0.158s
    sys 0m0.006s

    #!/usr/bin/env perl
    use 5.16.3;

    open my $fh, '<', 'logs1.txt';
    while (<$fh>) {
    chomp;
    if (/\b\w{15}\b/) {}
    }
    close $fh;

    #!/usr/bin/env python

    import re
    regex = re.compile(r'\b\w{15}\b')

    with open('logs1.txt', 'r') as fh:
     for line in fh:
      if regex.search(line):
       continue
Re:Perl 7 is going to be Perl 5.32, mostly by dgfitz on Wednesday June 24, 2020 @02:33PM (#23631982)
The python code should run much faster if you don't print..

Edit: perl is still faster, to be clear

Re:Perl 7 is going to be Perl 5.32, mostly by cutler on Wednesday June 24, 2020 @08:35PM (#23635496)
That's like saying they're both as fast if you amputate one of Perl's legs.
Re:Perl 7 is going to be Perl 5.32, mostly by mappu on Wednesday June 24, 2020 @06:23PM (#23634562)
I took some similar benchmarks recently: https://code.ivysaur.me/interpreter-binary-perf

Perl5 won the dec2bin benchmark.

The other thing I learned was that PHP's binary/decimal functions are two orders of magnitude slower, despite its core interpreter performance being best-in-class.

Re:Perl 7 is going to be Perl 5.32, mostly by cutler on Wednesday June 24, 2020 @08:37PM (#23635514)
On the other hand PHP has a PCRE jit option which manages to beat even Perl's regex implementation.
Re:Perl 7 is going to be Perl 5.32, mostly by rurban on Thursday June 25, 2020 @01:46AM (#23637293)
Yes but you can use that jit also with perl5. https://metacpan.org/pod/re::engine::PCRE2

It has even less backcompat problems than the native regex.

Re:Perl 7 is going to be Perl 5.32, mostly by kbenson on Wednesday June 24, 2020 @12:52PM (#23630512)
> it's even slower than Python.

It's faster at some things and slower at others. It's fairly similar in speed profile to Python in my eyes.

> Are you saying the language doesn't change much or that it doesn't crash?

Both is probably what was meant. They are literally changing the major version so they can change some backwards compatibility, as Perl has made strong backwards compatibility a goal and selling point for decades. You can take a script written in 2000, and it will likely run without problem if you run it on a Perl 5.30, released last year.

Re:Perl 7 is going to be Perl 5.32, mostly by 1996 on Wednesday June 24, 2020 @12:53PM (#23630519)
- Efficient: from prototype to deployment, it's a matter of days. The choice of styles let people use paradigms they are familiar with, meaning they do things quickly.

- Cheap: it does not cost much to hire someone to write perl. If they don't know how yet, the choice in style let them be efficient quickly. The code to be deployed is very lightweight, both in CPU and RAM usage.

- Stable: no API break. No new module that reinvent the wheel and breaks your codebase. Unit testing is about everywhere in cpan. Code written 20 years ago still run fine.

Re:Perl 7 is going to be Perl 5.32, mostly by continuational on Wednesday June 24, 2020 @02:02PM (#23631541)
The reason that code written 20 years ago still runs fine is that they rolled back 20 years of changes!
Re:Perl 7 is going to be Perl 5.32, mostly by 1996 on Wednesday June 24, 2020 @04:08PM (#23633241)
This is a pointless attack. The modules available on CPAN usually have a strong emphasis on backwards compatibility.
Re:Perl 7 is going to be Perl 5.32, mostly by yellowapple on Wednesday June 24, 2020 @03:38PM (#23632880)
> Also, perl is incredibly inefficient: it's even slower than Python.

That's debatable for single-threaded workloads (they're typically pretty comparable in my observation), and highly unlikely for multi-threaded workloads (Python has a global interpreter lock whereas Perl does not AFAICT; you can work around that in Python, but it typically involves spawning entirely separate processes, thus introducing IPC overhead that wouldn't be present in a Perl equivalent).

Looking at some comparative benchmarks (https://benchmarksgame-team.pages.debian.net/benchmarksgame/...), Perl seems to be faster in a slight majority of cases, and in nearly all cases has a lower memory overhead. Not that benchmarks really matter anyway, given that they're usually a poor indicator of real-world performance, but still.