I mean less focus on being “glue” between C code and more focus con optimizing the interpreter?
I mean less focus on being “glue” between C code and more focus con optimizing the interpreter?
If your ML model takes hours when it can take minutes, or takes days when it can take hours, you will move away. You could move away to another language or a faster interpreter but that's a different discussion.
> more focus con optimizing the interpreter
This is good but there's an upper bound to performance of interpreted languages. Maybe the Python interpreter could be as fast as V8, but it is unlikely to be fast as JVM. People will need to drop down to C / Fortran for whatever compute intensive work they're doing.
How much of this is done in Python, vs constructing instructions in Python to run on a GPU at uber speed?
I haven't seen many people doing ML in Python without one of these libraries, so I'd say it is mostly constructing instructions in Python and offloading the actual intensive work to these libraries (which may or may not run on GPU depending on your hardware).
Always was, always will be.
Related: When I search for help on a Python foundation library or built-in funciton, my Google search results are overwhelmed by "learn-to-program"-type of websites. I guess it makes sense: During the gold rush, don't dig for gold, rather sell shovels!
On the other hand, no one is doing the same for Bash.
You are using Bash because you know how to program something else and need to schedule it / wrap it in a shell script / etc. The fact that someone even knows Bash exists is a filter. Having an idea of where you might need to use it, a second filter. And having successfully done so, a third filter.
Python’s optimal use case does not relate to speed.