5 ms·

If CPU load is an issue, why would you be using an interpreter in the first place?

dsfyu404ed 9y ago
Just because those resources exist does not mean you get to park your 1997 Chevy Cavalier diagonal across three parking spaces. I'm not going to run your code on my server if your code uses resources so poorly that I can't run other things I want to run on my server.
- DigitalJack 9y ago
  You are getting downvotes, I suspect, because your comment makes no sense in the context of the post you replied to. Perhaps you meant to reply to GP?
zerkten 9y ago
It seems like people never make this assessment, or use the GIL argument to put interpreted languages down. I personally run into I/O bound problems way more often than CPU bound ones. That said, I'm mainly doing things in the realm of a Python web developer. Scientists probably hit CPU bound problems more often with Python, but seem to drop down to C/C++ extensions without needing to complain about the problems.
khedoros1 9y ago
A lot of the heavy lifting is done through calls to C libraries anyhow, with Python just being a convenient way to pass the data around.
- falcolas 9y ago
  Indeed, and in that case the GIL is effectively a non-issue (there's no requirement for the GIL to be held by non-python code).
  - Animats 9y ago
    No, no, if you're manipulating Python objects from C code, you have to hold the lock. You can release it only when not doing anything with objects in Python's memory space. Otherwise you get race conditions and intermittent crashes.
throwaway613834 9y ago
> If CPU load is an issue, why would you be using an interpreter in the first place? You're basically asking why NumPy, SciPy, Numba, etc. even exist. They exist because Python is ridiculously fast to develop in compared to, say, C++.
- CogitoCogito 9y ago
  By using numpy, etc. you're basically _not_ using the interpreter because you're using C/C++/fortran code that's been compiled with python bindings. To combine both your points, the best approach (if you like python) is to stick with python due to is ease of development and use libraries such as numpy as far as possible. However, if your use case is CPU bound but not served by those libraries, then you'll either need to develop your own extensions or throw away the interpreter altogether (and go with a different language).

Just because those resources exist does not mean you get to park your 1997 Chevy Cavalier diagonal across three parking spaces. I'm not going to run your code on my server if your code uses resources so poorly that I can't run other things I want to run on my server.

DigitalJack 9y ago
You are getting downvotes, I suspect, because your comment makes no sense in the context of the post you replied to. Perhaps you meant to reply to GP?

zerkten 9y ago

It seems like people never make this assessment, or use the GIL argument to put interpreted languages down. I personally run into I/O bound problems way more often than CPU bound ones. That said, I'm mainly doing things in the realm of a Python web developer. Scientists probably hit CPU bound problems more often with Python, but seem to drop down to C/C++ extensions without needing to complain about the problems.

khedoros1 9y ago

A lot of the heavy lifting is done through calls to C libraries anyhow, with Python just being a convenient way to pass the data around.

falcolas 9y ago
Indeed, and in that case the GIL is effectively a non-issue (there's no requirement for the GIL to be held by non-python code).
- Animats 9y ago
  No, no, if you're manipulating Python objects from C code, you have to hold the lock. You can release it only when not doing anything with objects in Python's memory space. Otherwise you get race conditions and intermittent crashes.

throwaway613834 9y ago

> If CPU load is an issue, why would you be using an interpreter in the first place? You're basically asking why NumPy, SciPy, Numba, etc. even exist. They exist because Python is ridiculously fast to develop in compared to, say, C++.

CogitoCogito 9y ago
By using numpy, etc. you're basically _not_ using the interpreter because you're using C/C++/fortran code that's been compiled with python bindings. To combine both your points, the best approach (if you like python) is to stick with python due to is ease of development and use libraries such as numpy as far as possible. However, if your use case is CPU bound but not served by those libraries, then you'll either need to develop your own extensions or throw away the interpreter altogether (and go with a different language).