Achieving High-Performance the Functional Way

Re:Achieving High-Performance the Functional Way by synergy20 on Sunday March 05, 2023 @04:55PM (#35034460)

the reality is, general programming language with FP capabilities is what flies in practice, pure FP language might be perfect, it's just hard to find coders for them, we will have to live with that.

for HPC and ML, Python is dominant, I would expect to enhance python somehow with FP instead of anything else, then adding c/c++/rust/fortran libraries(e.g numpy) for intensive computing needs.

[ Parent | on HN ]

Re:Achieving High-Performance the Functional Way by karmakaze on Sunday March 05, 2023 @05:17PM (#35034714)

Python isn't popular for data only because it's imperative, there's also the vast numerical processing ecosystem. Scala/Spark is an example where FP fits well.

[ Parent | on HN ]

Re:Achieving High-Performance the Functional Way by noloblo on Sunday March 05, 2023 @05:08PM (#35034601)

what about GIL? https://wiki.python.org/moin/GlobalInterpreterLock

why python can't thread? impact of GIL on python https://pythonspeed.com/articles/python-gil/

[ Parent | on HN ]

Re:Achieving High-Performance the Functional Way by synergy20 on Sunday March 05, 2023 @05:33PM (#35034889)

My understanding is that even with GIL removed today, Python is still not a performant language for cpu-intensive tasks, be it single core or multiple-core.

Python is better used as a glue language and leverage numpy etc to do the heavy lifting, numpy can work with multiple-core just like c/c++/rust languages can.

If you really need launch multiple python processes, the multiprocessing module came to rescue.

While not ideal, I don't see a showstopper to use Python for HPC's high and parallel computation needs at all.

[ Parent | on HN ]