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

211–220 of 251 posts

Re: Faster Python with Guido van Rossum

#211

Post by igouy »

KronisLV wrote: post #201
igouy wrote: post #87

Earlier quoted context omitted.

And some where JS is not 50x faster than Python: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

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

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

#212

Post by smallnamespace »

indymike wrote: post #83
colejohnson66 wrote: post #37

Earlier quoted context omitted.

> What I'd love is a language that can be compiled (and be highly optimized) and interpreted without changing it's behavior. The developer experience with an interpreter is fantastic, the performance of compiled code is... better. You mean something like a byte code like language with a JIT system? Like Java and C#? C# in particular now supports AOT compilation, but can still be run as “interpreted” CIL.

Having a VM / JIT in the middle is a way to get there, but ultimately, different. At least in Java's case, my code targets an abstraction instead of hardware, so I don't get the full benefit of compilation. Performance is part of the story... access to the OS and hardware is another.

Even native compilers like clang will use LLVM, and LLVM IR can look a lot like JVM bytecode.

The VM abstraction is not a barrier to fully optimizing for your architecture, but rather how much time you can spend converting IR/bytecode into assembly, whether you do it at runtime, and whether runtime information lets you optimize even further.

Re: Faster Python with Guido van Rossum

#213

Post by CraigJPerry »

igouy wrote: post #156
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…

> Each example just calls out to a very fast c library… No. https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

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

#214

Post by dzonga »

BiteCode_dev wrote: post #143
ctur wrote: post #4

I have become increasingly convinced Python as a language is a "trap" for any use of notable scale, be the scale about number of developers, codebase size, or performance requirements. It's a great 0->1 language and great at simple glue, but eventually you hit a wall and have to keep investing larger and larger amounts of people or computing resources to get continued returns... all due to fundamental design decision…

A trap for your dream world were you suddenly get google size ? Because I have a 1 million unique users video streaming service still running python 2.7, using a few servers. The thing has a mobile version serving a different media on the fly, encodes user uploaded videos, features comments, tagging, and even has machine learning detection of content now. It is still maintained by one single person, and he is not a p…

link to the site ?

Re: Faster Python with Guido van Rossum

#215

Post by takeda »

gizdan wrote: post #199
takeda wrote: post #180

Earlier quoted context omitted.

Do you have an article about that? I would be interested to learn more about it.

Sadly the page isn't available on Google Books anymore[0], you might still be able to get the book itself. There also might be a Hacker News thread on it too or it'll be on Reddit. It's one of those places I'll have seen it on. [0] https://books.google.co.uk/books?id=eulODwAAQBAJ&lpg=PA136&d...

Thanks.

Re: Faster Python with Guido van Rossum

#216

Post by vram22 »

BiteCode_dev wrote: post #174
ithrow wrote: post #160

Earlier quoted context omitted.

Even faster for 0->1, use Javascript, big ecosystem as Python but same language in front-end and back-end. Faster runtime also.

There are still no "rails" or "django" for JS. There are frameworks emerging with the same features, but they don't have close to the ecosystem. Meaning every time you want auth, social integration, etc. you have to reinvent the wheel. There is also the stdlib. JS doesn't have simple things built in like left trim a string, csv loading, uuid generation, etc. Then there is the API. Sorting in JS requires this weird -1…

>There is also the stdlib. JS doesn't have simple things built in like left trim a string,

Or left pad.

https://www.google.com/search?q=left+pad+js

left-pad as a service

https://news.ycombinator.com/item?id=11352315

https://news.ycombinator.com/item?id=11350651

https://news.ycombinator.com/item?id=11354770

Re: Faster Python with Guido van Rossum

#217

Post by manfre »

brundolf wrote: post #177
ctur wrote: post #4

I have become increasingly convinced Python as a language is a "trap" for any use of notable scale, be the scale about number of developers, codebase size, or performance requirements. It's a great 0->1 language and great at simple glue, but eventually you hit a wall and have to keep investing larger and larger amounts of people or computing resources to get continued returns... all due to fundamental design decision…

To add to this: any time somebody at my company who doesn't work on our Python services every day has to dip into them for a one-off task, it takes a day or two of troubleshooting their environment just to get to where they can start working with the actual code. And this isn't necessarily from scratch: any Python environment that's sat still for more than a few weeks becomes inevitably broken. It's a huge time-sink…

I recommend learning to use tox and virtualenvs to avoid this headache. A properly laid out project (of any language) should have a fast time from checkout to running tests.

For most python projects, that can be as simple as `pip install tox & tox`

Re: Faster Python with Guido van Rossum

#218

Post by [deleted] »

ferdowsi wrote: post #82
ck_one wrote: post #63

Earlier quoted context omitted.

+1 Would be cool if some experienced dev could share some estimates when the Python scaling issues start. When you build a backend using Python + Django/FastAPI, I assume in most cases the DB and not Python is the limiting factor. Moreover, you could always spin up more workers to mitigate scaling issues. When you train ML models, your Python code just calls C++ functions. Python is not a limiting factor here either.

I worked for a startup that built their services using Python and Twisted. The codebase was a monolith broken up into several Twisted services, by the time I left it was probably 200k LOC of Python. For us, the scaling problems started when we had two independent teams working in the same codebase. The extreme dynamism of the language meant that classes and data structures were being mutated willy-nilly in ridiculous…

[deleted]

Re: Faster Python with Guido van Rossum

#219

Post by bcrosby95 »

Cthulhu_ wrote: post #151
BiteCode_dev wrote: post #143

Earlier quoted context omitted.

A trap for your dream world were you suddenly get google size ? Because I have a 1 million unique users video streaming service still running python 2.7, using a few servers. The thing has a mobile version serving a different media on the fly, encodes user uploaded videos, features comments, tagging, and even has machine learning detection of content now. It is still maintained by one single person, and he is not a p…

It's a variation on cargo cult; you WISH you had the scaling problems that could be solved by using something a bit more performant. But solve the problem first, and solve it fast. It's why so many startups from the 2010's on used Ruby; they were productive in it, solving a real problem, rolling out features fast. I've worked in a few projects where they dove onto the cargo cult, of wishing they had the kind of reque…

Just write a stateless app tier. Doesn't matter what language you use at that point if you need to scale it out.

It doesn't require any extra work either. Just requires knowing what you're doing.

Re: Faster Python with Guido van Rossum

#220

Post by abdabab »

Decabytes wrote: post #61

Python will always be important to me. It's the first programming language that I've learned, and it allows me to support my family. It's awesome that almost any problem I have, there is a library or wrapper ready made for me to use. I can google just about any error and get a solution right away. But I've found that I really dislike maintaining larger Python codebases. Whenever I've tried to develop packages or libr…

> And when it comes to personal growth as a programmer, I find it's just too easy to stack ready made libraries on top of libraries, without ever coding things from scratch.

This is working as intended. This is how everything should be.

Post reply on HN