Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Faster Python with Guido van Rossum

softwareatscale.dev

Post reply on HN
Print view View original

181–190 of 251 posts

Re: Faster Python with Guido van Rossum

#181

Post by igouy »

Zababa wrote: post #176
CraigJPerry wrote: post #130

Earlier quoted context omitted.

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 example…

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.

Do you mean Python program[mer]s are less bored ?

Re: Faster Python with Guido van Rossum

#182

Post by rich_sasha »

joconde wrote: post #136
overgard wrote: post #90

Ugh. Python could be fast, but the python core team / GvR put so many ridiculous constraints on what can change that maybe at best it gets like 10% faster, some day. Anything meaningful means breaking compatibility with extensions, and they absolutely won't do that. I feel like GvR got burned in the python 2->3 transition, but he learned the wrong lesson. The lesson he seemed to learn was never break compatibility bu…

There is no way I'm doing anything serious in a language that decides to make us rewrite part of our work regularly. We have actual work to do... I think you underestimate how important stability is.

I was thinking the same until I had to do the change. It was surprisingly easy. And I had a lot of poorly tested code to port.

Re: Faster Python with Guido van Rossum

#183

Post by rich_sasha »

uyt wrote: post #155
overgard wrote: post #90

Ugh. Python could be fast, but the python core team / GvR put so many ridiculous constraints on what can change that maybe at best it gets like 10% faster, some day. Anything meaningful means breaking compatibility with extensions, and they absolutely won't do that. I feel like GvR got burned in the python 2->3 transition, but he learned the wrong lesson. The lesson he seemed to learn was never break compatibility bu…

> nor will they ever endorse something like PyPy What's their beef with PyPy?

PyPy is a trade off and not universally better. It has a larger memory footprint (already a bit of an issue for Python), higher startup times and incomplete compatibility, in particular with C compiled libs used precisely where performance matters.

Re: Faster Python with Guido van Rossum

#184

Post by rich_sasha »

nothrowaways wrote: post #171

There seem to be big appreciation for go language. How difficult is it to develop a language with (mostly) python syntax while keeping the performance of go? I guess most people who use python use it because of its aesthetics and might even never heard of the GIL issue in python, so i guess among all languages the python syntax is the most liked one.

Nim is basically this.

Re: Faster Python with Guido van Rossum

#185

Post by Zababa »

igouy wrote: post #181
Zababa wrote: post #176

Earlier quoted context omitted.

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.

Do you mean Python program[mer]s are less bored ?

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

#186

Post by igouy »

Mikeb85 wrote: post #178
igouy wrote: post #122

Earlier quoted context omitted.

> 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 ?

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.

Given that you say "basically glue" why the previous surprise about "basically using C types and GMP" ?

Re: Faster Python with Guido van Rossum

#187

Post by igouy »

ithrow wrote: post #179
igouy wrote: post #122

Earlier quoted context omitted.

> 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 ?

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.

The importance of looking at more than one measurement.

Re: Faster Python with Guido van Rossum

#188

Post by fasterbynight »

wenc wrote: post #169
prionassembly wrote: post #152

Earlier quoted context omitted.

I recently learned just enough Rust to use its ndarray crate and rewrite bottleneck bits of code. I used to think the whole "write inner loops in $fastlang, use $scriptlang as glue" was something of a lame "cope" (and I say this as someone who doesn't know $fastlang), but I'm seeing upwards of 100X time performance improvements for code that can't be hammered into numpy idioms. I can provide code examples. Edit: code…

Thanks for providing code. I’ve written code like that before and the first thing that jumps out at me is that you have for loops in Python code which isn’t slow but will never be as fast as loops in a static compiled language. Sometimes for loops are the most readable way of expressing a calculation but as a numerical computation person my instinct is to look for opportunities to vectorize by rewriting loops into ma…

I don't know about other languages, but in Julia I've heard people often say that loops end up faster than the equivalent vectorized code. So while this is true for Python/Matlab I don't think it is good universal advice.

That said, matrix notation can sometimes be the more readable way of expressing a calculation.

Re: Faster Python with Guido van Rossum

#189

Post by rowanseymour »

ck_one wrote: post #133
rowanseymour wrote: post #86

Earlier quoted context omitted.

I feel pretty similarly. Our product used to be a Python/Django monolith and over the years we've ended up pulling so much of the functionality out into services written in golang. It was fantastic for getting the product up and running relatively quickly, and we're still very happy to let Django take care of the frontend and database migrations. But when your codebase has gotten big, refactoring in Python feels like…

How do you you handle the communication between the Django codebase and the Go codebase? Does it produce a lot of overhead?

All the communication is initiated on the Django side and it's either HTTP and tasks queued in Redis depending on whether it needs to be synchronous. It adds a little extra complexity but it's also nice being able to stop and start services without bringing the whole system down.

Re: Faster Python with Guido van Rossum

#190

Post by prionassembly »

wenc wrote: post #169
prionassembly wrote: post #152

Earlier quoted context omitted.

I recently learned just enough Rust to use its ndarray crate and rewrite bottleneck bits of code. I used to think the whole "write inner loops in $fastlang, use $scriptlang as glue" was something of a lame "cope" (and I say this as someone who doesn't know $fastlang), but I'm seeing upwards of 100X time performance improvements for code that can't be hammered into numpy idioms. I can provide code examples. Edit: code…

Thanks for providing code. I’ve written code like that before and the first thing that jumps out at me is that you have for loops in Python code which isn’t slow but will never be as fast as loops in a static compiled language. Sometimes for loops are the most readable way of expressing a calculation but as a numerical computation person my instinct is to look for opportunities to vectorize by rewriting loops into ma…

Some of that Python is strange for numerical Python practices, yes, but I was aiming for close floating-point output equivalence. Rust ndarray provides the standard set of matrix ops, but I keep getting different results (\propto 1e-5 on a stable basis, which isn't quite a proof of incorrectness, but....) when I use too much numpy stuff like linalg.norm, etc. (ndarray slices in Rust are annoying to use because of lifetimes and such.)

I did my dissertation on symplectic exponential Runge-Kutta schemes with stable numerics for the big matrix exponentials needed (which have this specific structure that allow for theorems to be proven). But I didn't have time to write any code at all. I wonder if open source ODE solvers are getting good high-order symplectic methods by now...

Post reply on HN