Announcement

Collapse
No announcement yet.

HOPE: The Ease Of Python With The Speed Of C++

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #61
    Originally posted by TheBlackCat View Post
    If you looked at my examples you would see that is exactly what I did in the first and second case. You are right, technically that is not iterating over a sequence. But it is still not O(n) performance no matter what you do.
    well, hash table access is "constant time", so it is theoretically O(n), but that constant can be rather big
    Quite possibly premature optimization, without knowing more about the problem (in particular input size).

    Comment


    • #62
      Originally posted by erendorn View Post
      well, hash table access is "constant time", so it is theoretically O(n), but that constant can be rather big
      Quite possibly premature optimization, without knowing more about the problem (in particular input size).
      For the hash table alone. But you need to either loop over the string, and then use the hash table on each element of the string, or you would need to create a hash table, and loop over the string for each item in the hash table. Either way, the two together would not be O(n).

      Comment


      • #63
        Originally posted by TheBlackCat View Post
        Sorry, that is a typo. I screwed up the code tags and had to rush to fix it before the time limit expired. It should be "ch", not "count".

        But that was my third example, my first was from the earlier post.
        first and third examples have total complexity of O(n*k) where k is number of different characters
        and i am sure you put third one last because its loop body is much uglier than c++ counterpart
        Code:
        counts [ ch ] ++;

        Comment


        • #64
          Originally posted by pal666 View Post
          s.size ( ) - * boost :: max_element ( s | boost :: adaptors :: transformed ( std :: function < std :: size_t ( char ) > { [ & ] ( char c ) { return boost :: count ( s, c ); } } ) );
          Yeah, well, the thing is that anyone who knows Python would pretty much directly see what the previous Python function did.
          Now, I am by far a C++ expert, but I know my way around it, and that line is horribly unreadable.
          And no, even though boost is common, it is not standard C++.

          Comment


          • #65
            Originally posted by pal666 View Post
            and i am sure you put third one last because its loop body is much uglier than c++ counterpart
            Code:
            counts [ ch ] ++;
            No, I put the last one last because it much slower (using two loops instead of one loop and one hash table). Whether the first or second is faster depends on the string in question, but the third is always slower.

            And I don't think
            Code:
            counts [ ch ] ++
            is that much uglier than
            Code:
            counts [ ch ] += 1

            Comment


            • #66
              Originally posted by kigurai View Post
              Yeah, well, the thing is that anyone who knows Python would pretty much directly see what the previous Python function did.
              Now, I am by far a C++ expert, but I know my way around it, and that line is horribly unreadable.
              And no, even though boost is common, it is not standard C++.
              Yep, less lines does not equate to more readability
              By standards, he means can be compiled as standard C++. C++ should be used with external frameworks, the std is a good place to start, but I wouldn't do full fledged apps without a toolkit. No sense in rewritting everything by oneself.

              But here is a fully standard one for you
              Code:
              #include <algorithm>
              #include <unordered_map>
              
              int getmin(const std::string& str)
              {
              	std::unordered_map<char,int> counter;
              	int currentMax(0);
              	for (auto ch : str)
              		currentMax = std::max(currentMax, ++counter[ch]);
              	return s.size() - currentMax;
              }
              Or, maybe a bit more readable if you don't like to ++ variables:
              Code:
              #include <algorithm>
              #include <unordered_map>
              
              // can be defined as a lambda in getmin,
              // but I find it much easier on most people to define as a normal function
              // A template would do the trick too.
              typedef std::unordered_map<char,int> M;
              bool pairComparer(const M::value_type &i1, const M::value_type &i2)
              {
              	return i1.second<i2.second;
              }
              
              int getmin(const string& str)
              {
              	M counter;
              	int currentMax(0);
              	for (auto ch : str)
              		counter[ch] += 1;
              	auto maxPair = std::max_element(counter.begin(), counter.end(), pairComparer)
              	return s.size() - maxPair.second;
              }

              Comment


              • #67
                Originally posted by Alliancemd View Post
                The word "JIT" in there already calls to the bulls**t claims that it reaches C++ speed...
                Consider the use the authors are making of the tool. Astrophysical simulations can run for days or weeks or even months. Amortize the cost of just-in-time-compiling the Python code over such run times, it is not very bad at all.

                Comment


                • #68
                  Originally posted by hoohoo View Post
                  Consider the use the authors are making of the tool. Astrophysical simulations can run for days or weeks or even months. Amortize the cost of just-in-time-compiling the Python code over such run times, it is not very bad at all.
                  If it runs for months, don't use "faster python", use C++ or even Fortran, profile guided optimizations, and builds targeting the hardware you are using.
                  Python is largely fast enough for 99% of tasks, but at the time scales you are mentioning even 1.5x perf impact (some jit vs compiled) is a damn lot.

                  Comment


                  • #69
                    Originally posted by erendorn View Post
                    If it runs for months, don't use "faster python", use C++ or even Fortran, profile guided optimizations, and builds targeting the hardware you are using.
                    Python is largely fast enough for 99% of tasks, but at the time scales you are mentioning even 1.5x perf impact (some jit vs compiled) is a damn lot.
                    I do not disagree with you, Erendorn, that's the best way to go if it's within one's abilities.

                    However, I worked for several years in a Physics department at a large university doing system administration, and this is what I observed:

                    - Many grad students and younger professors who were spoon fed Python or Matlab or Mathematica as undergrads. They were essentially incapable of writing their own C or C++ code to do simulations - dangling pointers, memory leaks, etc.
                    - If you are such a person, then Python (Matlab, Mathematica) will let you write runnable code in a reasonable amount of time, whereas you might spend weeks getting some C or C++ code to work.
                    - Some of these people were aware enough that Python, say, was slower than well written C/C++, and they sought to leverage Python bindings to CUDA, or used specialized C++ libraries with Python bindings.
                    - It's the same as in the business sector (where I now work as a C++ programmer, lol): balancing development time against speed of execution.

                    Me, I personally can't write Python worth a damn, but I'm a wiz with C++. I spent a couple of years cutting my teeth on C++, not theoretical physics... these people were the opposite.

                    Comment


                    • #70
                      Originally posted by erendorn View Post
                      If it runs for months, don't use "faster python", use C++ or even Fortran, profile guided optimizations, and builds targeting the hardware you are using.
                      Python is largely fast enough for 99% of tasks, but at the time scales you are mentioning even 1.5x perf impact (some jit vs compiled) is a damn lot.
                      Perhaps I misunderstand what JIT compilers do. As I understand they will compile code fragments to binary and then cache the translated binary code - so they do not repeatedly compile the same stuff over and over. If this is the case then once all the frequently executed code paths in a program have been compiled we should see the overhead of a JIT compiler fall close to zero.

                      Is this incorrect?

                      Comment

                      Working...
                      X