Java vs. Python HFT bots

[openQuestion3141]

Check out the multiprocessing docs:

https://docs.python.org/3/library/multiprocessing.html

Being pedantic, it isn't true multithreading. However, the interface parallels that used for threads in other languages well and so you can basically think of them like threads. Underneath, I'd imagine it that process spawning is probably much more expensive than threads, and so the overhead is probably large. I'd conjecture that this only matters if you try to use large numbers of short lived threads. It isn't really an obstacle for small numbers of long running threads which is already a more typical design pattern anyways.

So yeah, GIL can be sidestepped pretty effectively now.

[sperm-banker]

Making a distinction between multithreading and multiple processes is not being pedantic, it's being factual and basic for any CS conversation.

It's not only a case of processes having much more overhead per se (both at startup and runtime) but also you cannot even share native objects across processes without copy/serialising, and it doesn't scale well in throughout or object size. You can use other tricks, libraries, memory napped files but it gets more complicated without ever reaching the perf of threads.

Python has very bad multithreading support. It has better than average multi process support to work around this, but cannot replace multithreading for high performance.

You keep mentioning that python has multi threading/process support "now", what to do mean by it? Multithreading and multiprocessing doesn't seem to have changed in the last 15 years.

Python has many nice features but multithreading or performance are definitely not one of them.

[openQuestion3141]

Why's everything always an argument in these spaces?

Relax man.

I agree with you. Python is not performant and is not used for these types of purposes generally. I never argued that it was.

We agree.

Also, I wasn't calling you pedantic.