2 ms·

>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.

>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 ago
It'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.