Comment by lunias

Comment by lunias 4 days ago

Sure, there's multiprocessing, but historically no multithreading (relatively recently there is the free-threading interpreter). Each of those processes / threads will also execute slowly compared to most other languages. But we agree Python is not performance oriented... I'm just curious why people think it's a good trade-off when I suspect that writing the same code in say, Java, will take roughly the same time, be easier to maintain (compiler assisted refactoring, type safety, etc), and execute faster.

fatbird 4 days ago

I worked on a python codebase for several years that had over two million LoC. The code was well-organized and under constant development by at least ten devs. There were Java components in the larger project that were occasionally touched on, and it was always slower to work with those parts.

A well organized python codebase really is faster to work on than other languages. If your dev work is slowing down as the codebase grows, that's a sign you're accruing tech debt by not keeping up with organizing it.

Reply View 0 replies

ActorNightly 4 days ago

After having worked with Java extensively during my time at Amazon, especially during the log4shell bullshit, I can safely say that if you think Java is viable for anything these days, you lack real world experience of how actual good, efficient dev process is one.

But on a slightly less edgy note: java doesn't have a fast REPL loop, near anywhere near the amount of libraries available for it as Python does, and requires tuning to actually make it performant. Its by far not the same amount of time to develop. It doesn't have things like jupyter notebooks for prototyping, doesn't have an easy to use interpreter, doesn't have ability to inject code during debug sessions, and doesn't have easy system integration (i.e with a module, you can install it in editable more, you can have an executable you can run from command line, e.t.c), and doesn't have things like dynamic import (where you can dynamically reload modules as the program is running, can't (easily) import inside function statements, and so on)

>Sure, there's multiprocessing, but historically no multi-threading

Functionally, when the cpu switches context the main thing that matters is the stack frame. This happens in both threading or running multiprocessing. The only difference is between the two is a) data access and b) initial startup time.

a is solved by unix pipes,which is already a part of multiprocessing in python, which are plenty fast for anything you wanna do, and b is solved by spinning up the processes ahead of time in worker pools, which is already part of multiprocessing in python.

Reply View 6 replies

lunias a day ago

You appear to have been traumatized by Java... You can sub in any statically typed, compiled language.
The key distinction between multiprocessing and multithreading is that in multithreading all the threads of a process share the same memory. Are you saying that Python uses pipes for providing shared access to memory across processes? It looks like there is: multiprocessing.shared_memory, but this all seems more complicated than it is in other languages. Perhaps it's not?
I will 100% give you that Python has more libraries, but that's the only real advantage I was able to glean.

Reply View | 5 replies
- ActorNightly a day ago
  
  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. Pretty much almost as fast as threading.
  >You appear to have been traumatized by Java
  Not really, I just have standards. Java is just a poorly designed language with poor community support. Look at the amount of code it takes to send an HTTP request in Java, versus Python.
  
  Reply View | 4 replies
  
  lunias a day ago
  
  > 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 my point.... (Java)
  var client = HttpClient.newHttpClient(); var request = HttpRequest.newBuilder().uri(URI.create("https://api.example.com/data")).build(); var response = client.send(request, HttpResponse.BodyHandlers.ofString());
  versus (Python)
  response = requests.get('https://api.example.com/data')
  Yes, it's more verbose, but not to the extent that I'd trade the compiler and performance for the less verbose version especially considering auto-complete in IDEs.
  
  Reply View | 3 replies