News for hackers. Stuff that matters.
Re:Faster Python with Guido van Rossum by igouy on Thursday October 07, 2021 @12:31PM (#28788595)
And some where JS is not 50x faster than Python: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
Re:Faster Python with Guido van Rossum by KronisLV on Thursday October 07, 2021 @05:36PM (#28792422)
Those are some pretty nice synthetic benchmarks! However, if you'd like a look at a more real world scenario or two, have a look at the TechEmpower benchmarks as well.

For example, here are filters for both JS and Python: https://www.techempower.com/benchmarks/#section=data-r20&hw=...

Do note that for most of the "realistic" stacks out there, you'd probably want to filter out all of the micro or no framework approaches, to compare something like Express and Koa against Django and Flask, like in the following link: https://www.techempower.com/benchmarks/#section=data-r20&hw=...

Here's the summary page with composite scores across all tests (though you might also want to filter by data storage solution, for example, MySQL): https://www.techempower.com/benchmarks/#section=data-r20&hw=...

To summarize, the performance from the best to worst currently is:

  Composite scores: Koa (JS) > Express (JS) > Flask (Python) > Django (Python)
Re:Faster Python with Guido van Rossum by igouy on Thursday October 07, 2021 @06:16PM (#28792791)
Thanks.

> "more real world scenario" "realistic"

I'm of the opinion that "Real programs may not be representative either".

http://www.larcenists.org/Twobit/bmcrock.temp.html

We have to show that they are or discover they are not.

Re:Faster Python with Guido van Rossum by KronisLV on Friday October 08, 2021 @03:00AM (#28796481)
In this context I believe that if a benchmark does exactly that your software would do in a production environment (shuffling JSON around and accessing a DB), then such a benchmark is probably a rough indicator of how well any stack would work, as long as the source code is also written in an idiomatic fashion.

Of course, if you can, take benchmarks with a grain of salt and ideally do some prototyping and load testing.

Re:Faster Python with Guido van Rossum by igouy on Friday October 08, 2021 @11:30AM (#28800367)
> … does exactly that your software would do…

Is "exactly" really the situation, or is it that the benchmark does something kind-of like one of the use cases?

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Re:Faster Python with Guido van Rossum by KronisLV on Saturday October 09, 2021 @05:23AM (#28808274)
In the case of the TechEmpower benchmarks, i'd argue that it's actually pretty much the same thing as real world applications: https://github.com/TechEmpower/FrameworkBenchmarks

For example, look at a full platform Java Spring Boot example here: https://github.com/TechEmpower/FrameworkBenchmarks/tree/mast...

The controller code, the model code and even the repository code are all very reflective of the primitives you'd find in production code.

The only differences would be when you add additional complexity, such as validations and other code into the mix, such as additional service calls etc., but if even the simpler stuff in Python (as an example) would be noticeably slower, then it stands to reason that it wouldn't get magically faster on the basis of less overhead alone.

The exceptions to this which i could imagine would be calls to native code, since the aforementioned Python has an amazing number crunching or machine learning support, but that is hardly relevant to web development in most cases.

Otherwise we risk running into the "No true Scotsman" fallacy: https://en.wikipedia.org/wiki/No_true_Scotsman

In such a case, we'd adamantly claim that these benchmarks are simply not good enough even for educated guesses and we'd have to build out our full system to benchmark it, which no one actually has the resources for - in practice you'd develop a system and then would have to do a big rewrite, as was the case with PHP and Facebook, as well as many other companies.

On the other hand, premature optimization and dogmatic beliefs are the opposite end of the spectrum: you don't need to write everything in Rust if using Ruby would get your small application out the door in a more reasonable amount of time.

There are no easy answers, everything depends on the context (e.g. small web dev shop vs an enterprise platform to be used by millions) and the concerns (e.g. resource usage and server budget vs being the first to market, as well as developer knowledge of tech stacks, for example market conditions of PHP vs Rust).

Regardless, in my eyes, there's definitely a lot of value in these attempts to compare idiomatic interpretations of common logic for web development primitives (serving network requests in a known set of formats).

Re:Faster Python with Guido van Rossum by igouy on Saturday October 09, 2021 @01:11PM (#28811517)
(Incidentally, thank you for the pleasant conversation.)

> … which no one actually has the resources for…

That webpage references "JSMeter: Characterizing Real-World Behavior of JavaScript Programs".

iirc they instrumented a web browser to collect "real-world" data and demontrated that wasn't like the behavior of benchmark code.

That webpage references "A comparison of three programming languages for a full-fledged next-generation sequencing tool" — "reimplemented … in all three languages and benchmarked their runtime performance and memory use."

That's in-practice.

> … you don't need to write everything in Rust if using Ruby…

Performance doesn't matter until it matters.

As-in the home page quote and reference — "It's important to be realistic: most people don't care about program performance most of the time."

https://benchmarksgame-team.pages.debian.net/benchmarksgame/

Re:Faster Python with Guido van Rossum by Mikeb85 on Thursday October 07, 2021 @12:51PM (#28788913)
Did you look at the source of the programs where Python was competitive?

Python basically using C types and GMP to write C in Python...

Re:Faster Python with Guido van Rossum by CraigJPerry on Thursday October 07, 2021 @01:20PM (#28789403)
I suspect that site is some kind of in-joke. E.g. read the regex-redux example in say c#, now look at the go version, now the python version…

It’s not really what you’d expect for a site called computer language benchmarks game. Each example just calls out to a very fast c library (pcre2) to perform the heavy lifting regardless of which language is being “benchmarked”.

Seems a pretty pointless site.

The other examples have similar nonsense.

Re:Faster Python with Guido van Rossum by Zababa on Thursday October 07, 2021 @02:43PM (#28790502)
On this page: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

> "... a pretty solid study on the boredom of performance-oriented software engineers grouped by programming language."

I think that's probably the best way to describe it.

Re:Faster Python with Guido van Rossum by igouy on Thursday October 07, 2021 @02:51PM (#28790587)
Do you mean Python program[mer]s are less bored ?
Re:Faster Python with Guido van Rossum by Zababa on Thursday October 07, 2021 @02:54PM (#28790627)
Oh no, the programs aren't bored at all, they are very busy, which is the problem.

Edit to answer yours: There may be less Python programmers that are bored, or less performance-oriented Python programmers.

Re:Faster Python with Guido van Rossum by igouy on Thursday October 07, 2021 @02:01PM (#28789956)
> Each example just calls out to a very fast c library…

No.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Re:Faster Python with Guido van Rossum by CraigJPerry on Thursday October 07, 2021 @06:36PM (#28792990)
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Your python 3 one isnt the fastest python 3 solution, it’s this one which uses pcre2

Re:Faster Python with Guido van Rossum by igouy on Friday October 08, 2021 @12:00PM (#28800727)
That's correct, the Python program that uses pcre2 is faster.

The slower program is an example from that website of a regex program which does not " just calls out to a very fast c library (pcre2)…".

Re:Faster Python with Guido van Rossum by makapuf on Thursday October 07, 2021 @04:41PM (#28791765)

  from re import sub, findall
That's where pcre2 is called (or a finely tuned regex c lib)
Re:Faster Python with Guido van Rossum by igouy on Thursday October 07, 2021 @06:02PM (#28792656)
Re:Faster Python with Guido van Rossum by makapuf on Friday October 08, 2021 @01:24AM (#28796015)
Re:Faster Python with Guido van Rossum by igouy on Friday October 08, 2021 @11:33AM (#28800401)
And? CPython is implemented in C.

Here's some of a comment from _operator.c

"This module exports a set of functions implemented in C corresponding\n\ to the intrinsic operators of Python. For example, operator.add(x, y)\n\ is equivalent to the expression x+y."

Why wouldn't you expect that CPython regex would "ultimately" be written in C?

Re:Faster Python with Guido van Rossum by igouy on Thursday October 07, 2021 @01:11PM (#28789264)
> Did you look at the source of the programs…

Did you? :-)

That Node pidigits program also uses GMP.

Besides those 2, did you notice other JS programs not 50x faster than the corresponding Python programs ?

Re:Faster Python with Guido van Rossum by ithrow on Thursday October 07, 2021 @02:46PM (#28790527)
There are 2 programs there that are 50x faster in JS, other 40x, other 35x, other 16x, a couple 7x, not sure what are you arguing about.
Re:Faster Python with Guido van Rossum by igouy on Thursday October 07, 2021 @03:02PM (#28790727)
The importance of looking at more than one measurement.
Re:Faster Python with Guido van Rossum by Mikeb85 on Thursday October 07, 2021 @02:45PM (#28790516)
I never made the assertion JS is 50x faster...

But everyone knows it is significantly faster than Python. Probably at least a few times for pure JS vs. pure Python programs. Not that it matters, Python is basically glue to run mostly C and C++ programs.

Re:Faster Python with Guido van Rossum by igouy on Thursday October 07, 2021 @03:01PM (#28790706)
Given that you say "basically glue" why the previous surprise about "basically using C types and GMP" ?
Re:Faster Python with Guido van Rossum by Mikeb85 on Thursday October 07, 2021 @03:20PM (#28790925)
Because it's obviously not the idiomatic way to use Python. No one is going to bother writing a program that way in Python, they'd just write it in C or C++ then link it.
Re:Faster Python with Guido van Rossum by igouy on Thursday October 07, 2021 @06:06PM (#28792699)
Sorry, I gave up thinking I knew what people would or wouldn't bother doing a long time ago.