Python’s Weak Performance Matters

Post by pjmlp » Wed, Feb 07, 2018, 9:29 AM UTC

joshuamorton wrote: post #72

pjmlp wrote: post #60

Earlier quoted context omitted.

Depends, I bet they can be easily translated to some LINQ like implementation in C++17. List comprehensions are just syntax sugar for map/filter/fold.

A jaunt through SO didn't give anything reasonable. This is what SO had to offer: https://stackoverflow.com/questions/36339533/how-to-generate... , and a quick check of new C++17 features didn't show any that would obviously improve on that. There's nothing implicitly stopping you from doing some macro magic to implement it, but its not there naturally.

    #include "cpplinq.hpp"

    int computes_a_sum ()
    {
        using namespace cpplinq;
        int ints[] = {3,1,4,1,5,9,2,6,5,4};

        auto result =    from_array (ints)
                      >> where ([](int i) {return i%2 ==0;})  // Keep only even numbers
                      >> sum ()                               // Sum remaining numbers
                      ;
        return result;
    }

Post by pjmlp » Wed, Feb 07, 2018, 9:32 AM UTC

e12e wrote: post #69

pjmlp wrote: post #57

Earlier quoted context omitted.

Every time this comes up, there are also the good examples of Lisp, Dylan and Smalltalk as languages that as dynamic as Python, while enjoying relatively good JIT compilers.

Which of course python has too (pypy). Although it depends on what your bar for "relatively good" is.

Post by klibertp » Wed, Feb 07, 2018, 9:35 AM UTC

kamaal wrote: post #83

klibertp wrote: post #81

Earlier quoted context omitted.

The lack of REPL compounds with long compilation times, which is practically a feature of C++ and not going to go away anytime soon. The effect is that, when you explore a new API or need to tune parameters to some function call deep in the call stack, you're an order of magnitude slower than with Python (or Lisp, Scala, F#, Haskell, or even Nim or plain C (b/c compilation times)). If you know exactly what you need t…

If you are developing your code as a small tiny functions getting stitched later. Then writing unit test cases will solve this problem too.

Post by pjmlp » Wed, Feb 07, 2018, 9:37 AM UTC

klibertp wrote: post #88

pjmlp wrote: post #59

Earlier quoted context omitted.

Common Lisp, Dylan and Smalltalk are as dynamic as Python, yet they all enjoy of good quality native code compilers (AOT/JIT).

To be honest, Dylan is not exactly alive anymore. CL and Smalltalk still have commercial vendors providing implementations, Dylan has currently two implementations, but one of those (Gwydion) is completely neglected and the other (OpenDylan) has maybe 5 developers working on it in their spare time. It's a shame because even with its verbose syntax Dylan is a nice language, with a module system, with object system bas…

Post by luispedrocoelho » Wed, Feb 07, 2018, 9:46 AM UTC

aldanor wrote: post #85

luispedrocoelho wrote: post #36

Earlier quoted context omitted.

OP here. Speed is the main motivation, but total time is TimeToWriteCode + TimeToRunCode. Python has the lowest TimeToWriteCode, but very high TimeToRunCode. C++ has lowest TimeToRunCode, but high TimeTowWriteCode. Haskell is often a good compromise for me. Also, with Haskell, it can be very easy to take advantage of 20 CPU cores, while I don't have as much familiarity with high-level C++ threading libraries.

@ the OP - not to sound hostile, but you write code (like in the example here [1]) that is bound to be slow, just from a glance at it. vstacking, munging with pandas indices (and pandas in general), etc; in order for it to be fast, you want pure numpy, with as little allocations happening as possible. I help my coworkers “make things faster” with snippets like this all the time. If you provide me with a self-containe…

    interesting = set(line.strip() for line in open('interesting.txt'))
    total = 0
    for line in open('data.txt'):
        id,val = line.split('\t')
        if id in interesting:
           total += int(val)