3 ms·
>Though Python has been making a lot of inroads I weep to think of of all the cycles wasted on expensive tax payer funded hardware due to using Python over muc
by voidlogic 11y ago
>Though Python has been making a lot of inroads
I weep to think of of all the cycles wasted on expensive tax payer funded hardware due to using Python over much faster Intel Fortran. We are talking like orders of magnitude.
I once ported a fellow undergrads astronomy program from Python to C+CUDA and it ran on their personal workstation in less than a day, when it had been using the department cluster for a week before :/
People often hate on Fortran because its old and creeky when it often as fast or faster than C...
- GFK_of_xmaspast 11y agoWhat about expensive tax payer funded scientists.
- gh02t 11y agoPython isn't necessarily replacing the hardcore number crunching code (at least in my industry). It's more becoming the glue code to wrap those libraries and make them more accessible. That and data processing. I don't see people running massive simulations on clusters using mpi4py or whatever (thank god). Even then, in a lot of cases programmer time is infinitely more expensive than CPU time, so it often still makes sense if Python is the more accessible choice.
- voidlogic 11y ago>Even then, in a lot of cases programmer time is infinitely more expensive than CPU time, so it often still makes sense if Python is the more accessible choice. I think this is generally true outside of scientific computing, but often not the case here. Esp. if you consider the low salaries of scientists in the public service compared to private industry. Even in the private sector I have routinely made things an order of mag. faster saving the need to massively scale out. People also forget about total cost of ownership, 10 servers costs much less than 10x what 100 servers require operate when you consider cooling, networking, power, part replacement etc.
- gh02t 11y agoIt's true in scientific computing too... there's plenty of times when a quick Python script that takes 10 minutes to bang out is better than writing a chunk of C++ in an hour. The lost time isn't necessarily in the salary of the scientist, it's in the time spent. A lot of the scientists working in the big government research labs have one-of-a-kind knowledge and their time is at a premium in terms of other stuff they could be working on. But I agree, if you're writing a massively parallel simulation in Python and running it on a supercomputer it's a net waste of money. There's a big trend in the government projects to build libraries like Trilinos or MOOSE, which work kind of along the same philosophy as NumPy - let specialists implement the parts that really matter (in terms of computational expense) in a compiled language and let the scientists glue together those parts in a higher level language. It's a good strategy IMO, especially for technologies like CUDA where there's a huge benefit but also a steep learning curve.