5 ms·

"because we all know it can work and that it will be faster" Speed of execution depends more on the programmer's expertise than the language used.

jrockway 17y ago
Not really true. I can write the same algorithm in Perl as in Haskell, and the Haskell always runs faster.
- dualogy 17y ago
  So maybe he meant "on the expertise of the programmer" -- of the language/compiler...
- fhars 17y ago
  But then your expertise is not that different from your expertise. Your perl will probably still be faster overall than a beginner's haskell, not for the same algorithm, but for solutions to the same problem. Knowing which algorithms perform well for a given problem solved in perl is the most relevant part of expertise.
- anonjon 17y ago
  Chances are that the majority of developers won't find the most efficient algorithm to solve the problem. (vs. the most efficient implementation of that algorithm... which is clearly going to be in a combination of C and assembly anyway). Anyway, the guy using the good algorithm ends up with the fastest code. Different compilers will produce different quality of code. Question is, if I am using C++ vs. a guy using Perl, will I ever reach the efficient algorithm? I might call it quits when I finally get something to compile and not segfault. (Of course even this is kind of a strawman, because the perl guy can just reimplement in C++ when he figures out that he wants more speed out of his good algorithm).
  - fauigerzigerk 17y ago
    "Chances are that the majority of developers won't find the most efficient algorithm to solve the problem." If that is so and the code does need to run fast or use little memory then the majority of developers would benefit from a fast language. Very often, code doesn't need to run super fast. Memory usage and concurrency (the GIL) are greater issues with dynamic languages in my view.
    - jrockway 17y ago
      I don't get the constant complaints about the GIL. Letting your Python program run on 2 cores will make it 2x faster at best. Rewriting it in, say, Javascript or Lisp or Haskell or Java will make it run 2-50x faster on one core. After you get your 50x speedup, then you can worry about the 4x you'll get from buying 3 more processor cores. (And oh yeah; it's only shared-memory concurrency that things like the GIL affects. If you have a job to do that wants to use 8 cores, split the job up into 8 parts and invoke your program 8 times. There's your 8x speedup.)
      - ramchip 17y ago
        > 2x faster at best That's if you're CPU-bound. I don't use Python, but I made an image acquisition program in C++ which could be a relevant example. We wanted to save the images to disk in real-time (30-60FPS). Doing this in the acquisition loop would make the software unusable (the goal is video-rate confocal microscope imaging); it's far too long, and much of it is just due to disk writes being slow, not to the compression time. Using a thread pool was the solution, not because of an actual increase in speed, but because from the loop's POV the write went from blocking to non-blocking so the CPU stopped wasting time waiting for the disk. We also wanted shared memory since there can be a lot of image data which is shared between the image compression & saving, display, and possibly statistics or filtering modules.
        jrockway 17y ago
        Dunno about Python, but Perl has a library to do all disk writes in a separate (p)thread, so your main control thread never blocks on IO. (This is in addition to the usual event-loop tricks; I know Python can do nonblocking IO that way.)

jrockway 17y ago

Not really true. I can write the same algorithm in Perl as in Haskell, and the Haskell always runs faster.

dualogy 17y ago
So maybe he meant "on the expertise of the programmer" -- of the language/compiler...
fhars 17y ago
But then your expertise is not that different from your expertise. Your perl will probably still be faster overall than a beginner's haskell, not for the same algorithm, but for solutions to the same problem. Knowing which algorithms perform well for a given problem solved in perl is the most relevant part of expertise.
anonjon 17y ago
Chances are that the majority of developers won't find the most efficient algorithm to solve the problem. (vs. the most efficient implementation of that algorithm... which is clearly going to be in a combination of C and assembly anyway). Anyway, the guy using the good algorithm ends up with the fastest code. Different compilers will produce different quality of code. Question is, if I am using C++ vs. a guy using Perl, will I ever reach the efficient algorithm? I might call it quits when I finally get something to compile and not segfault. (Of course even this is kind of a strawman, because the perl guy can just reimplement in C++ when he figures out that he wants more speed out of his good algorithm).
- fauigerzigerk 17y ago
  "Chances are that the majority of developers won't find the most efficient algorithm to solve the problem." If that is so and the code does need to run fast or use little memory then the majority of developers would benefit from a fast language. Very often, code doesn't need to run super fast. Memory usage and concurrency (the GIL) are greater issues with dynamic languages in my view.
  - jrockway 17y ago
    I don't get the constant complaints about the GIL. Letting your Python program run on 2 cores will make it 2x faster at best. Rewriting it in, say, Javascript or Lisp or Haskell or Java will make it run 2-50x faster on one core. After you get your 50x speedup, then you can worry about the 4x you'll get from buying 3 more processor cores. (And oh yeah; it's only shared-memory concurrency that things like the GIL affects. If you have a job to do that wants to use 8 cores, split the job up into 8 parts and invoke your program 8 times. There's your 8x speedup.)
    - ramchip 17y ago
      > 2x faster at best That's if you're CPU-bound. I don't use Python, but I made an image acquisition program in C++ which could be a relevant example. We wanted to save the images to disk in real-time (30-60FPS). Doing this in the acquisition loop would make the software unusable (the goal is video-rate confocal microscope imaging); it's far too long, and much of it is just due to disk writes being slow, not to the compression time. Using a thread pool was the solution, not because of an actual increase in speed, but because from the loop's POV the write went from blocking to non-blocking so the CPU stopped wasting time waiting for the disk. We also wanted shared memory since there can be a lot of image data which is shared between the image compression & saving, display, and possibly statistics or filtering modules.
      - jrockway 17y ago
        Dunno about Python, but Perl has a library to do all disk writes in a separate (p)thread, so your main control thread never blocks on IO. (This is in addition to the usual event-loop tricks; I know Python can do nonblocking IO that way.)