Pyston 2.1 Is Blowing Past Python 3 Performance (phoronix.com) 72
Camel Pilot writes: Pyston 2.1, a closed-source but faster and highly-compatible implementation of the Python programming language, significantly outperforms Python 3 in a variety of benchmarks. All the system details and benchmarks in full can be found over on OpenBenchmarking.org.
Why? (Score:3)
Why would anyone close source a language?
Re:Why? (Score:5, Informative)
The language isn't closed source, the compilers are. Intel does this with C/C++, Borland Pascal and Microsoft BASIC and C# are all closed source languages.
Microsoft VB and C# compiler is open (Score:5, Informative)
Microsoft's compiler for C# is open. .Net Core repo.
It's part of the
https://github.com/dotnet/core [github.com]
C# is an ECMA standard, like JavaScript, and is also an ISP standard.
You'll also find the Visual Basic toolchain there.
Microsoft Basic ended a couple decades ago.
They've open sourced one of many versions.
https://github.com/microsoft/G... [github.com]
As to the Borland product, that does seem to be closed.
I think they switched to Delphi about 25 years ago.
Delphi was based on Turbo Pascal, which I think was based on Object Pascal, which was based on Pascal.
Re: (Score:2)
Turbo Pascal (CPM) came before Object Pascal (Apple Lisa), which you're probably confusing with Borland Pascal (DOS, Win3.x), which started out as rebranded Turbo with objects and grew into Delphi, and borrowed from UCSD Pascal (PDP11).
Thanks (Score:2)
Thanks for that. The Pascal family of languages were in my peripheral vision during that time.
I decided to learn VB6 rather than Delphi. I've wondered what I would have learned differently from what I learned doing VB6. From VB6 I first learned to really appreciate objects, I finally really understood WHY use them. I also got to learn about the Win32 API writing low-level hacks to access Windows functions that were officially not available from VB.
Perl lays objects bare; the objects are naked so you can ea
Re: (Score:1)
Re: (Score:2)
Man I loved Delphi back in the day. It was orders of magnitude superior to Visual Basic. And the speed and compile file size were excellent yes but also fantastic was that it came with a boatload of useful UI widgets.
Re: (Score:1)
Lazarus (https://www.lazarus-ide.org/ - IDE and GUI tools) and Free Pascal (https://www.freepascal.org/ - object pascal compiler and RTL) are the open source, multiplatform equivalents today.
Re: (Score:2)
I'm not a programmer and never used VB besides chasing after the runtime too often. Pascal did teach me about structured programming and the benefits of strong typing. Perhaps if I'd been exposed to computers 20 years earlier, I would have grokked objects quicker.
Re: (Score:2)
> Perhaps if I'd been exposed to computers 20 years earlier, I would have grokked objects quicker.
For me, building a GUI is what made objects "pop".
A password field and a calendar picker DO things (methods), have properties, and respond to things happening, such as clicks. It's natural to think of them as objects, to wrap up their behavior, properties, and events together to represent a password field as a "thing".
Single line text input, multline text input, and password field all have a lot of common p
Re: (Score:2)
Yea, dealing with OS/2's WorkPlaceShell helped a lot with my understanding objects as everything is an object with that GUI. Desktop is of class folder. Someone even wrote a CD player and media player descended from the folder class and I've inherited maintenance of the screen saver which is descended from the lockup class.
Windows COM is basically a bad (but maintained) implementation of IBM's SOM.
Re: (Score:2)
I had started to add, I learned from other languages why not EVERYTHING should be an object. Not everything takes actions, has useful properties, and useful events.
I prefer:
seconds_day = 24 * 60 * 60
Over:
seconds_day.setValue(24.mutiply(60.multiply(60.value).value))
as long as it's compatible with Python 3 (Score:2)
Only problem with closed source stuff is they want to steer you to their platform. As long as Pyston 2.1 is completely compatible it's just a complier.
Re:as long as it's compatible with Python 3 (Score:5, Insightful)
It's "highly compatible" which means that it's not "fully compatible" which means you are going to hit something really weird and difficult when you try to port back. Fighting with weird compilers and their bugs can be some of the nastiest stuff going.
The real python people have PyPy which kind of has the same problem but isn't closed and looks like it has better benchmarks [pypy.org] than piston, just from a brief compare of the line size on probably completely unrelated and incomparable benchmarks. I'd trust PyPy much more than a closed implementation. Also, if you do end up being forced to migrate back there's likely to be a bunch of other people with the same problem so you won't have to do it alone.
Re: (Score:2)
Exactly, yes there are closed compilers in the world but they are artifacts of the past before open source methodology won the software wars.
Re: (Score:3)
Except for all the Intel compilers, and all the special purpose compilers, sure.
Re: (Score:2)
You could argue that Intel's compilers are "special purpose compilers," since their main selling point seems to be that they can exploit undocumented features of Intel chips.
Re: (Score:3)
Re: (Score:3)
You could argue anything for the flimsiest of reasons. You can also argue that all compilers are special purpose. Software developers are "special purpose" computer users.
Re: (Score:3)
There's also Cython, which will just translate your Python code to C and compile it into a library for you.
Re: (Score:2)
It's "highly compatible" which means that it's not "fully compatible"
Yes, that is pretty much a red flag for me too.
Also, if you have serious performance issues in Python, just embed C modules for the heavy lifting. It is not very difficult to do, real C skills stipulated.
Re: (Score:3)
It's "highly compatible" which means that it's not "fully compatible"
You can probably say that about two different implementations of any language - C, C++, Javascript... There is never a non-buggy implementation (most bugs in common compilers are of course fixed but there will always be some rare corner case somewhere) which means that there will always be a behavior in one implementation that isn't the same as in another. Most languages are sufficiently complex that it is very hard to have 100% compatibility.
You have to look at the details of what they mean by "highly comp
Re: (Score:3)
It isn't though it is an embrace and extinguish platform. I thought we were more or less done with this particular flavor of fuckery.
Re: (Score:2)
Only problem with closed source stuff is they want to steer you to their platform.
That's the only problem with a closed source toolchain? Here you have a compiler that's claiming to be faster than the original, open source implementation. Aren't you even curious as to why it might be faster, and what shortcuts it might be taking to achieve those results? If you're paranoid, I'd also think you'd be curious about what kinds of code it tucks in there without telling you, perhaps to facilitate things like remote telemetry. And failing all of that, isn't a compiler that can easily be ported t
Re: (Score:2)
It is only 20% faster. That is barely noticeable.
Re: as long as it's compatible with Python 3 (Score:2)
Does the language have a set of standard tests that can be run for a new compiler? If so, probably no big deal using a compliant proprietary compiler. If not, then the language probably isn't well-defined enough to acheive real portability.
Re: (Score:2)
Technically sure but why would anyone take a blast to the past and close source a compiler TODAY in a world in which the closed vs open battle has solidly been won by open.
Re: (Score:2)
Why would anyone close source a language?
To make money. Tons of money. And when enough people have moved, extend and extinguish the original.
Re: (Score:2)
To make money. Tons of money.
Pyston 2.1 costs $0.
It isn't easy to make money at that price point.
Re: (Score:3, Funny)
Re: (Score:2)
That is even worse.
Re: (Score:2)
Today it may be $0. If it takes off and becomes popular, people start coding for it, perhaps start using some Pyston-only features, then prices go up above $0. A free version may still exist, for personal use and perhaps limited to 72 runtime before requiring restart. Even if you stick with pure Python only, when faced with a decision of paying for closed source Python interpreter or using open source version which requires you to buy/rent more servers to accomplish the very same task, the math with dictat
Re: (Score:2)
What is the point of gratis closed-source software? Sounds extremely fishy to me. What's hiding in that code?
Re: (Score:2)
Real-world advantage: (Score:5, Funny)
You can now process twice as many white-spacing complaints per hour.
Re: (Score:1)
You made beer spray out of my nose, I needed that, thanks.
Re: (Score:1)
Good thing it wasn't fireball.
Fuck them (Score:5, Interesting)
OK, its shitty of them to be closed source, that's a given. But also the version scheme is terrible. They shouldn't call it 2.1. It's confusing because it's not clear whether it requires Python 2. I mean it was a real pain for people to shift from 2.7 to 3 and now this thing reminds of that.
Re: (Score:2)
To make things even funnier it should work with both versions 2 and 3.
Re: (Score:2)
Re: (Score:2)
Tough one (Score:1)
Fastest tricycle in the world! (Score:5, Insightful)
I'm not sure that "I need the best performance possible" is a good fit with "I want to implement this in Python". Better to use a compiled language for the high-performance routines, instead?
Re: (Score:3)
Yeah, but you know how it really goes. "I already wrote this thing, and now I want it to run faster."
Re:Fastest tricycle in the world! (Score:5, Interesting)
Of course. But Python is a great glue language. That's why high performance computing uses Python a lot, combined with high performance, compiled libraries for use from within Python. If you happen to like Python, which I do, Cython works quite well as a means of compiling for speed certain performance-sensitive routines. In many respects you end up with the best of both worlds. Given these facts, I don't see a lot of use for this proprietary implementation in the high-performance computing genre. But I could see it used on the web server, to get more performance out of django, for example.
Re: (Score:2)
I agree that python is a great glue language. I have some code that extensively uses numpy and many other high performance libraries. Python also has tools like numba if you need to speed up something not already available in a low level language. I worked in some code yesterday and half the performance of my program was in a single function about 10 loc long. I rewrote that function using numba and doubled the performance of my program.
Re: (Score:2)
I'm not sure that "I need the best performance possible" is a good fit with "I want to implement this in Python". Better to use a compiled language for the high-performance routines, instead?
Tell it to Facebook, which in its wisdom decided the best way to scale its service was to reimplement PHP from scratch.
Re: (Score:2)
Pretty much so. Or use Python as Glue and for parts that are not performance critical and embedded C modules for the heavy lifting. I made pretty good experiences with that.
Re: (Score:1)
It's common for orgs to think "developer time is more important than cpu time".
Then they get a bunch of users and realize that they have to scale. With technical debt in the form of potentially millions of lines of Python, they have two option:
1. Re-write everything in something else
2. Swap out the interpreter and just re-write some parts that use libs iwth C-extensions.
Sometimes, the latter is the cheaper option.
Of course, the whole mess could have been avoided if they thought in the long-term a bit more.
Lacking comparison against pypy and cython (Score:5, Informative)
Re: (Score:3)
last time I tried pypy and cython, there were pretty annoying compatibility issues with the reference python interpretor. Maybe they are fixed now. Maybe pyston has the same problems.
Re: (Score:3)
I recently adapted a large Python codebase to work on Pypy. But "adapted" isn't really the right word, because pretty much everything just worked the first time. There was one very minor issue I had to deal with from a small difference in behavior, but that was it. If you haven't tried it in a while, it's probably worth taking another look.
So much to say, but this seems to be (Score:4, Informative)
Re: (Score:2)
Yeah, stay away from this. There's no reason to use it.
Re: (Score:2)
I expect Pyston to announce that Python contains Pyston's precious intellectual property and every Python user must pony up a $600 site license. It's happened before.
Strange (Score:1)
Re: (Score:2)
Not so strange. Two benchmarks are slower: python_startup and json_loads. Pyston is a JIT, so it's not surprising that startup would be slower. I would guess that json_loads spends almost all its time in native C code, so there just isn't that much Python runtime to speed up.
Re: (Score:1)
Re: (Score:2)
I wouldn't assume it is all that silly. There are definitely use-cases for small programs running short jobs (following the basic Unix philosophy) and startup time might be the dominate time in running such programs, meaning that you might care about a benchmark that tests startup times.
Re: (Score:1)
Re: (Score:2)
I think you're dismissing a use-case that you aren't much interested in. A "worthy" benchmark is a benchmark that somebody cares about - and there are real (and rather common) use cases for short-running programs. Of course that particular benchmark may show a Python JIT compiler at a disadvantage compared to pre-compiled or plain interpreted - but this is good to know about if your application is this style of program. And again, most of the basic Unix programs fall into this category - so there are a whol
Should be Easy to Build Fast Python Compiler (Score:2)
I have written a handful of interpreter languages. There is not much prohibiting Python from being a fast running. It's just another one of those things for which, for whatever reason, nobody has stepped up to the plate. Personally, I think it's just because it feels and seems in so many ways like a toy language. I think it gained popularity because it's pretty good at presenting academic example cases and then, later, due to all the data science and machine learning libraries for it (which I use on a d
Re: (Score:2)
There is not much prohibiting Python from being a fast running. It's just another one of those things for which, for whatever reason, nobody has stepped up to the plate.
They already did. Pypy is a well supported, highly compatible, JIT enabled, open source Python engine. It's still slow compared to statically typed languages, but it's a lot faster than CPython.
Re: (Score:3)
They already did. Pypy is a well supported, highly compatible, JIT enabled, open source Python engine. It's still slow compared to statically typed languages, but it's a lot faster than CPython.
Python is very statically typed, more so than any other language. There is only one type, "pointer to an object". What makes compiling/speed-up tough are the mutable objects. You can add/change methods and properties after an object is instantiated.
Re: (Score:3)
It doesn't seem to support tuples - I can find a proposal among the ECMA's GitHub repos, but it's clearly very much a work in progress: an issue to allow ordering comparisons [github.com] was opened only two days ago. Or are you proposing that JS Arrays are compatible with tuples but more versatile? If so, I'm dubious: aside from ordering, there's also the critical distinction that tuples are immutable.
FWIW I would also consider h
"Pyston 2.x still is (sadly) binary-only for now." (Score:2)
"binary-only" ?
WTF?
Why are Phoronix using those weasel words for Closed Source ?
How much was slashdot paid (Score:1)
Use-case?? (Score:2)
What is the use-case for a closed source version of an open-source language that already has a multitude of easy ways to increase performance from pypy/cython to gpu compatible libraries.