I think it’s a great baseline. Within academic context, Python (and perhaps Matlab) are extremely common for data analysis. I doubt many would transition code to other languages unless strictly needed such as the case in the article. Showing how to “simply” speed up code like the article does is a great way to snag speed even if you don’t analyze timing, and just replicate steps from this article.
Having done stuff myself as part of research, and having people I know go from developer jobs to research jobs, I can safely say scientists generally do not make good code. Regardless of language. An article like this gives good steps to take from start to end, and would be a valuable tool in a possible transition to better code.
I can absolutely confirm. I work in a specialized industry where we have a team of PhDs in our R&D team that writes quick and dirty code in Fortran. That’s what they know, and it’s what they’re most productive with.
Our production code is in Python. We took one of their solutions and made it way faster, and the main improvement was to restructure the code to not need everything in memory at once. Basically, they were processing data in 4D space, but only needed 3D worth of data at a time, and most of the time was being spent in memory allocation. So we drastically dropped memory usage and memory allocation by simply changing how they iterated, which also meant we could parallelize it, further increasing performance.
They’re paid to come up with the algorithms, I’m paid to make it run fast in production. We looked into Rust, but for this project, Python got us well within a reasonable running time and Rust would’ve requested retaining a lot of our team, but it’s still on the table if we need more performance.
I think it’s a great baseline. Within academic context, Python (and perhaps Matlab) are extremely common for data analysis. I doubt many would transition code to other languages unless strictly needed such as the case in the article. Showing how to “simply” speed up code like the article does is a great way to snag speed even if you don’t analyze timing, and just replicate steps from this article.
Having done stuff myself as part of research, and having people I know go from developer jobs to research jobs, I can safely say scientists generally do not make good code. Regardless of language. An article like this gives good steps to take from start to end, and would be a valuable tool in a possible transition to better code.
I can absolutely confirm. I work in a specialized industry where we have a team of PhDs in our R&D team that writes quick and dirty code in Fortran. That’s what they know, and it’s what they’re most productive with.
Our production code is in Python. We took one of their solutions and made it way faster, and the main improvement was to restructure the code to not need everything in memory at once. Basically, they were processing data in 4D space, but only needed 3D worth of data at a time, and most of the time was being spent in memory allocation. So we drastically dropped memory usage and memory allocation by simply changing how they iterated, which also meant we could parallelize it, further increasing performance.
They’re paid to come up with the algorithms, I’m paid to make it run fast in production. We looked into Rust, but for this project, Python got us well within a reasonable running time and Rust would’ve requested retaining a lot of our team, but it’s still on the table if we need more performance.