SoylentNews is people
SoylentNews
from the out-with-the-old,-in-with-the-new dept.
Submitted via IRC for TheMightyBuzzard
This morning at The Perl Conference in the Cloud, Sawyer X announced that Perl has a new plan moving forward. Work on Perl 7 is already underway, but it's not going to be a huge change in code or syntax. It's Perl 5 with modern defaults and it sets the stage for bigger changes later. My latest book Preparing for Perl 7 goes into much more detail.
Perl 7.0 is going to be v5.32 but with different, saner, more modern defaults. You won't have to enable most of the things you are already doing because they are enabled for you. The major version jump sets the boundary between how we have been doing things and what we can do in the future.
Remember, Perl was the "Do what I mean" language where the defaults were probably what you wanted to do. In Perl 4 and the early days of Perl 5, that was easy. But, it's been a couple of decades and the world is more complicated now. We kept adding pragmas, but with Perl's commitment to backward compatibility, we can't change the default settings. Now we're back to the old days of C where we have to include lots of boilerplate before we start doing something:
[...]
This is slightly better with v5.12 and later because we get strict for free by using setting a minimum version:
[...]
Perl 7 is a chance to make some of these the default even without specifying the version. Perl 5 still has Perl 5's extreme backward compatibility behavior, but Perl 7 gets modern practice with minimal historical baggage.
Source: https://www.perl.com/article/announcing-perl-7/
(Score: 0) by Anonymous Coward on Monday June 29 2020, @06:57PM (2 children)
Okay, I've done more testing because you got me interested. Short summary: unbuffered IO is dreadfully slow, buffered IO is adequately fast but still not as fast as other scripting languages.
I took a 100 million byte binary file and then wrote six programs to traverse the file and print the last few bytes. Raku 2020.06 single byte read: almost 14 minutes. Raku 2020.06 read in 64k buffered chunks: 0.35 seconds (Raku 'Hello World is 0.22 seconds.), and Raku on my machine has a 0.22 seconds tartup time. C single byte read: 1.04 seconds. C read in 64k buffered chunks: 0.021 seconds. Python single byte read: 17 seconds. Python read in 64k buffered chunks: 0.06 seconds (Python 'Hello World' is 0.01 seconds.).
So with 64k buffered reads, Raku is 6 times slower than C and 3 times slower than Python (if you ignore the startup overhead). With the single byte (unbuffered) reads, Raku is around 750 times slower than C and 50 times slower than Python. Damn.
(Score: 2) by bzipitidoo on Monday June 29 2020, @09:46PM (1 child)
I expect one reason the C program is so fast is that, under the hood, the C stdio library really is buffering the file read even when the program is reading only one byte at a time. Evidently, Raku is not.
I guess it comes down to whether an app programmer should have to worry about I/O buffering, or not. And the way programming has evolved over the years, with the pushing of everything that can be pushed off to the computer, such as memory management (smart pointers) and hashing, then, absolutely yes, buffering for fast I/O should be the system's problem, not the programmer's problem. Thanks for looking into this.
(Score: 0) by Anonymous Coward on Tuesday June 30 2020, @12:35AM
Thank you - I jump at any excuse to play with Raku, and I was upset when I saw such terrible performance. I'm not thrilled with a 6x gap, but for most tasks that's acceptable.