3 ms·

> Because I'm not aware of one, as long as you don't try to write Java code in Python. That means you are aware of one. Anyways, I guess I have my answer, per

> Because I'm not aware of one, as long as you don't try to write Java code in Python. That means you are aware of one. Anyways, I guess I have my answer, performance problems just aren't very common for many programmers. Keep in mind that profiling is only a solution to certain problems, due to Amdahl's law. To say that all interesting problems fit in that mould is disingenuous. > it is not really a huge problem to write a little code in C. Sure, but any language can do that. GCC is fast, but I thought we wanted to write code in something higher level? Or did we just give up?

slurgfest 15y ago
Whatever language you use, there are going to be many ways of writing slow code. The reason people use threads very heavily in (say) Java is that it is the way things are done effectively on that platform, because there isn't really anything better. It's not because it is globally the best way to do things in every language and condition. So it doesn't make sense to insist that exactly the same pattern be the 'best' solution in every other language. If I naively apply a Java "best practice" in LISP and get bad performance, does that mean LISP is suddenly unsuitable and fraught with horrible performance problems? Probably not: rather, it means that I'm newer to LISP than I am to Java, and that is why my program is not performing as well. Again - I am not aware of any devastating performance problem with Python - and in general I don't hear anything about the GIL except when someone is trashing Python from a list of talking points. You suggest I'm being disingenuous by attributing to me the statement that "all interesting problems" are solved by profiling. But this is really dishonest, as I didn't say anything like that to begin with. Nobody was even discussing "all interesting problems". The right way to deal with Python programs that perform poorly, in PRACTICE, is to start by measuring - and then focus your optimization effort on the parts of the code which are actually creating the problem. The vast majority of the time, there would be no need to switch off of Python, but even in those incredibly rare cases it is certainly possible to write a little function in C and call it a day. Not to start by switching to LISP. LISP is not a miracle panacea. Ruby is not. Python is not. For the purposes of optimizing highly performance-sensitive parts of a program, I prefer writing C to writing LISP. For the purpose of writing new software, I would in many cases choose Python and leave performance concerns to when they are actually demonstrably important, because I tend to get more-than-acceptable performance from Python in most cases. I like C just fine, I have written C for many years - in the event I am ever facing a problem which is magically impossible to solve in Python, I will not hesitate to use C. That is not "giving up". That is simply saying that there really is NOT any devastating reason why someone should avoid Python out of some evidence-free anxiety about performance. In the worst case, you can still use C to handle the nasty bits. So I have NO reason to switch to LISP, least of all some perceived performance advantage due to a lot of hand-waving about the GIL. But anyone who wants to use it should feel free, I am not about to mount some kind of advocacy campaign against tools I don't happen to use.
- oconnore 15y ago
  > The reason people use threads very heavily in (say) Java is that it is the way things are done effectively on that platform, because there isn't really anything better. It's not because it is globally the best way to do things in every language and condition. No, the reason threads are used very heavily in Java (and elsewhere) is that we have hit the ceiling of single threaded performance in silicon based processors. If you want to scale, you add more processors. Right now, I can't write a shared address space, pure-Python, trivially parallel program that performs significantly [1] better on a 2011 8 core i7 than on a single core Pentium 4 from almost ten years ago. That seems silly to me, but I understand that you can still build cool things with Python, and I'm not suggesting that you stop doing so. I am working with Python, too, and I love it. I was simply suggesting that Python is missing an opportunity to become a more powerful, more general purpose language. [1] We do have to take into account some improvements in branch prediction, cache sizes, memory speeds, etc.

slurgfest 15y ago

Whatever language you use, there are going to be many ways of writing slow code. The reason people use threads very heavily in (say) Java is that it is the way things are done effectively on that platform, because there isn't really anything better. It's not because it is globally the best way to do things in every language and condition. So it doesn't make sense to insist that exactly the same pattern be the 'best' solution in every other language. If I naively apply a Java "best practice" in LISP and get bad performance, does that mean LISP is suddenly unsuitable and fraught with horrible performance problems? Probably not: rather, it means that I'm newer to LISP than I am to Java, and that is why my program is not performing as well. Again - I am not aware of any devastating performance problem with Python - and in general I don't hear anything about the GIL except when someone is trashing Python from a list of talking points. You suggest I'm being disingenuous by attributing to me the statement that "all interesting problems" are solved by profiling. But this is really dishonest, as I didn't say anything like that to begin with. Nobody was even discussing "all interesting problems". The right way to deal with Python programs that perform poorly, in PRACTICE, is to start by measuring - and then focus your optimization effort on the parts of the code which are actually creating the problem. The vast majority of the time, there would be no need to switch off of Python, but even in those incredibly rare cases it is certainly possible to write a little function in C and call it a day. Not to start by switching to LISP. LISP is not a miracle panacea. Ruby is not. Python is not. For the purposes of optimizing highly performance-sensitive parts of a program, I prefer writing C to writing LISP. For the purpose of writing new software, I would in many cases choose Python and leave performance concerns to when they are actually demonstrably important, because I tend to get more-than-acceptable performance from Python in most cases. I like C just fine, I have written C for many years - in the event I am ever facing a problem which is magically impossible to solve in Python, I will not hesitate to use C. That is not "giving up". That is simply saying that there really is NOT any devastating reason why someone should avoid Python out of some evidence-free anxiety about performance. In the worst case, you can still use C to handle the nasty bits. So I have NO reason to switch to LISP, least of all some perceived performance advantage due to a lot of hand-waving about the GIL. But anyone who wants to use it should feel free, I am not about to mount some kind of advocacy campaign against tools I don't happen to use.

oconnore 15y ago
> The reason people use threads very heavily in (say) Java is that it is the way things are done effectively on that platform, because there isn't really anything better. It's not because it is globally the best way to do things in every language and condition. No, the reason threads are used very heavily in Java (and elsewhere) is that we have hit the ceiling of single threaded performance in silicon based processors. If you want to scale, you add more processors. Right now, I can't write a shared address space, pure-Python, trivially parallel program that performs significantly [1] better on a 2011 8 core i7 than on a single core Pentium 4 from almost ten years ago. That seems silly to me, but I understand that you can still build cool things with Python, and I'm not suggesting that you stop doing so. I am working with Python, too, and I love it. I was simply suggesting that Python is missing an opportunity to become a more powerful, more general purpose language. [1] We do have to take into account some improvements in branch prediction, cache sizes, memory speeds, etc.