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

Python 3.14 is here. How fast is it?

blog.miguelgrinberg.com

Post reply on HN
Print view View original

571–579 of 579 posts

Re: Python 3.14 is here. How fast is it?

#571

Post by ActorNightly »

lunias wrote: post #570
ActorNightly wrote: post #569

Earlier quoted context omitted.

No im saying that you can transport data over unix sockets, which are in memory, and python has that as part of multiprocessing. The way python multiprocessing is set up is that it acts like a thread - when you launch a function, it copies the memory of the current process into the new one. You pay the startup overhead, so instead you launch worker processes ahead of time, and transport data to them over unix pipes.…

> it copies the memory of the current process into the new one And if that memory is large enough then you OOM, so you would have to manage shared memory separately to prevent it from being copied into each process. It's not impossible, just complicated for some use-cases where using threads is a preferable paradigm. > Look at the amount of code it takes to send an HTTP request in Java, versus Python This is kind of…

>And if that memory is large enough then you OOM

OOM is not an issue these days lol. Memory is dirt cheap, and the amount of memory that gets copied is miniscule per process.

There is still also the design of the application, just like with threading.

>(Java)

Forgetting the main class there, and also any additional headers that you need to send.

Re: Python 3.14 is here. How fast is it?

#572

Post by lunias »

ActorNightly wrote: post #571
lunias wrote: post #570

Earlier quoted context omitted.

> it copies the memory of the current process into the new one And if that memory is large enough then you OOM, so you would have to manage shared memory separately to prevent it from being copied into each process. It's not impossible, just complicated for some use-cases where using threads is a preferable paradigm. > Look at the amount of code it takes to send an HTTP request in Java, versus Python This is kind of…

>And if that memory is large enough then you OOM OOM is not an issue these days lol. Memory is dirt cheap, and the amount of memory that gets copied is miniscule per process. There is still also the design of the application, just like with threading. >(Java) Forgetting the main class there, and also any additional headers that you need to send.

> the amount of memory that gets copied is miniscule per process

This is what is not always true. Sometimes you have a processing context that is GB in size, in which case scaling via multiple processes is not as simple as if you had access to threads that share that context by design. You will run out of memory really quickly if you spin up enough processes, and even if you have unlimited RAM you could have used 1/nth the memory. If you implement some method of sharing memory between processes to consume less overall, it will still come at the expense of speed and complexity.

> Forgetting the main class there

In Java 21+ you can omit it:

    void main() {     
        System.out.println("Hello, World!"); 
    }
But this is neither here nor there, I think it's well worth paying that tax. You only type it once, right?

Re: Python 3.14 is here. How fast is it?

#573

Post by lunias »

ActorNightly wrote: post #571
lunias wrote: post #570

Earlier quoted context omitted.

> it copies the memory of the current process into the new one And if that memory is large enough then you OOM, so you would have to manage shared memory separately to prevent it from being copied into each process. It's not impossible, just complicated for some use-cases where using threads is a preferable paradigm. > Look at the amount of code it takes to send an HTTP request in Java, versus Python This is kind of…

>And if that memory is large enough then you OOM OOM is not an issue these days lol. Memory is dirt cheap, and the amount of memory that gets copied is miniscule per process. There is still also the design of the application, just like with threading. >(Java) Forgetting the main class there, and also any additional headers that you need to send.

Here is something I find quite funny, when I search multithreading vs multiprocessing on google I get the following AI response:

    [Multithreading] Cons:
    A single thread crash can bring down the entire process. 
    Not ideal for CPU-bound tasks on a single core due to limitations like Python's Global Interpreter Lock (GIL)
So, it assumes that I'm using Python... and that's why threads are not preferable... got it.

Re: Python 3.14 is here. How fast is it?

#574

Post by lmm »

KK7NIL wrote: post #476
lmm wrote: post #276

Earlier quoted context omitted.

If you restrict yourself to programs that don't need an OS or hardware, you're going to be looking at a pretty small set of programs.

I don't, but I do restrict that you run it on the same OS as it was designed for.

The program may work fine on its original OS, and the OS may work fine on its original hardware, but for someone trying to actually run their business or what have you on the software these facts are often not particularly helpful.

Re: Python 3.14 is here. How fast is it?

#575

Post by a96 »

cap11235 wrote: post #207
7952 wrote: post #205

Earlier quoted context omitted.

Given how mature emulation is now why couldn't that just continue to be possible into the future?

Or get an IBM 360 and have support for the next two thousand years, which is the choice our parents made.

Rich parents.

Re: Python 3.14 is here. How fast is it?

#576

Post by a96 »

JodieBenitez wrote: post #369
makestuff wrote: post #170

Earlier quoted context omitted.

As a java backend dev mainly working on web services, I wanted to like python, but I have found it really hard to work on a large python project because the auto complete just does not work as well as something like java. Maybe it is just due to not being as familiar with how to properly setup a python project, but every time I have had to do something in a django or fast api project it is a mess of missing types. Ho…

Pycharm has been fine. Just disable the AI stuff and you get accurate completion. It even has completion for Django ORM stuff, which is heavily dynamic.

Pycharm has "AI stuff" now?

Re: Python 3.14 is here. How fast is it?

#577

Post by physicsguy »

coldtea wrote: post #551
OutOfHere wrote: post #414

Earlier quoted context omitted.

If you think Python is nice for scientific computing, you must have never tried Matlab. Python is pretty clunky in comparison in its syntax for scientific computing.

Never heard of people who didn't hate Matlab.

Hate is a strong word, but my biggest concern was that it's a closed ecosystem with a high license fee, especially when you start to add modules on.

Re: Python 3.14 is here. How fast is it?

#579

Post by repsilat »

throwaway314155 wrote: post #540
repsilat wrote: post #286

Earlier quoted context omitted.

For compute-heavy code "100x slower than C++" is a good rule of thumb in my experience in python 3.10.

Maybe when you are reinventing the wheel instead of using e.g. numpy, Jax, PyTorch. Python is an ecosystem some of which is tooling built in C/C++. There’s no reason to ignore those libraries just because C devs like to roll their own everything.

There's an Amdahl-like effect, where "100x slower" means that anything nontrivial in pure python ends up being fat in your flamegraphs, even if your "heavy lifting" core algorithmic stuff uses some nice fast libraries.
Post reply on HN