Earlier quoted context omitted.
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" ?
Faster Python with Guido van Rossum
191–200 of 251 posts
Re: Faster Python with Guido van Rossum
#192Earlier quoted context omitted.
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
#193Earlier quoted context omitted.
For your first point, I don't think a language such as JavaScript -is- much better, which is why Typescript was invented as an alternative for larger codebases/organizations
TypeScript:JS is a lot like mypy:Python; the only real difference is that Python adapted so that mypy (originally envisioned as its own language) code is also valid Python as well as the reverse, obviating the need for a compilation step to run mypy in the Python runtime (whereas TS has to compile to JS to run); also, mypy has mypyc to compile (currently, only a subset of) mypy code to something more efficient than n…
Type inference & hinting at the IDE level is just not as developed either
Re: Faster Python with Guido van Rossum
#194I 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…
Re: Faster Python with Guido van Rossum
#195There 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
#196I 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…
Shrug.
Re: Faster Python with Guido van Rossum
#197Earlier 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/...
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
#198I 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…
As someone with nearly two decades of experience with Python and who has deployed it in production in high impact scenarios, I’d like to nuance the above for people who think Python is only good for prototyping and that you have to rewrite in a “proper” programming language. This is the kind of blanket thinking to avoid. I think the rewriting part is only necessary if there’s some characteristic in your use case that…
I wouldn't call it an attempt. I mean, sure it has no chance against for example Rust, but Python's type system is actually quite decent and I think it is more powerful than the one from Go. Also you have freedom of using both nominal and structural typing if you chose.
The only problem I have with it when I have to use a package that don't have types, but fortunately that is happening less and less.
Some package authors refuse to add types, but others provide stubs to solve that problem. For example boto3-stubs provides types for boto3.
I really like that thanks to types I can also easily refactor code without worrying about breaking something in the process. I suspect if types existed and were popular with Python 2 then the whole Python 2 -> Python 3 migration would be a non issue.
Re: Faster Python with Guido van Rossum
#199Earlier quoted context omitted.
Also, pretty sure Python was called out as one of the main reasons why some hundred of Google Video engineers couldn't keep up with YouTube prior to Google's purchase. Python might not be the most performant, but once you need the scale, it's a good problem to have because at that point, your product has already made it.
Do you have an article about that? I would be interested to learn more about it.
[0] https://books.google.co.uk/books?id=eulODwAAQBAJ&lpg=PA136&d...
Re: Faster Python with Guido van Rossum
#200Earlier quoted context omitted.
I am probably the most commercially successful user of the multiprocessing module :) It's basically fine anywhere you need a function call that you can dispatch out to like 50 or 500 workers on a queue and then do something after that returns, but any shared memory or IPC between the workers is up to you. Python is also fine for webserving because most web servers pre-fork workers or whatever, so this doesn't come in…
> any shared memory or IPC between the workers is up to you. There is this: - https://docs.python.org/3/library/multiprocessing.shared_mem... - https://docs.python.org/3/library/queue.html - https://docs.python.org/3.8/library/multiprocessing.html#mul... - https://docs.python.org/3.8/library/multiprocessing.html#mul... > It's harder if you want to do something different where you want threaded workflows with synchron…