2 ms·
>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 miniscu
by ActorNightly 1y ago
>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.
- lunias 1y ago> 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?
- lunias 1y agoHere 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.