Announcement

Collapse
No announcement yet.

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

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

  • Originally posted by mmstick View Post
    1) You're really naive. Fortran is faster than C which is faster than C++. Julia makes heavy use of the best of C and Fortran math libraries so it is close to Fortran performance.
    Fortran is indeed faster than C and C++ because of forbidden aliasing.
    The C subset of C++ is of course as fast a C (that has been shown by benchmarks of compiling C projects with C and C++ compilers, but as it's the exact same code, there's of course no reason that performance should be different).
    The non-C features of C++ are faster than the same features handwritten in C, because the compiler optimize them. (So all in all, C is actually slower than C++)
    Calls to libraries are pretty much the same regardless of language. Saying one language is faster because it can call Fortran libraries is silly.

    Comment


    • Originally posted by TheBlackCat View Post
      All the benchmarks I have seen put Julia's performance at about 6 times slower than C or C++. Do you have benchmarks showing Julia with better performance than C or C++ using the same libraires?
      Benchmarks are on their website, as are links to the original source code for those benchmarks, Benchmarks are carried out regularly which is also charted on the website. http://julialang.org/benchmarks/

      Comment


      • Originally posted by mmstick View Post
        Benchmarks are on their website, as are links to the original source code for those benchmarks, Benchmarks are carried out regularly which is also charted on the website. http://julialang.org/benchmarks/
        So it looks like pretty much everything is slower than C for Julia. I can't really see the axes on the plot, but it looks like one benchmark might be a bit faster (although looking at the C code I would be surprised if doing multiple type conversions at every step of the loop like that, which Julia doesn't do, is the fastest implementation).

        Comment


        • Originally posted by TheBlackCat View Post
          So it looks like pretty much everything is slower than C for Julia. I can't really see the axes on the plot, but it looks like one benchmark might be a bit faster (although looking at the C code I would be surprised if doing multiple type conversions at every step of the loop like that, which Julia doesn't do, is the fastest implementation).
          The homepage for Julia shows actual numbers -- not sure how you missed that. It topples the C implementation in a few benchmarks even if it loses some. If you think their implemetation is not the same as Julia's, why not submit a patch?

          In any case, C/C++/Python isn't nearly as convenient as Julia. Try doing these in the above:

          Code:
          # gratio returns the value of the golden ratio.
          gratio() = (1 + 5^0.5) / 2
          
          # fib prints the Nth fibonacci number(s).
          fib(x::Int) = int((gratio()^x - (1-gratio())^x) / 5^0.5)
          fib(range::UnitRange{Int}) = {fib(x) for x = range}
          fib(array::Array{Int,1}) = {fib(x) for x = range}
          
          # squared squares the input.
          squared(x) = x^2
          squared(numbers::Array) = {x^2 for x = numbers}
          squared(numbers::UnitRange) = {x^2 for x = numbers}
          
          # average returns the average.
          average(x::Array) = sum(x) / length(x)
          
          # digits returns the number of digits in the number.
          digits(x::Int) = itrunc(log10(x)) + 1

          Comment


          • You know the actual language used isn't a big huge factor in performance if coded optimally, right? The algorithms used is a much bigger factor in performance. Those algorithms might be sub-optimal for a given language however, due to language constraints. That's the main reason C is so bloody powerful, since you can essentially abuse the language half to death to squeeze out performance gains. I automatically disregard any argument of "language speed" as a result, unless someone can give me a specific task and a specific reason why one language is faster/slower then the other.

            Comment


            • Originally posted by mmstick View Post
              The homepage for Julia shows actual numbers -- not sure how you missed that. It topples the C implementation in a few benchmarks even if it loses some.
              I did miss that. Although it only topples C for 2, and loses for 4.

              Originally posted by mmstick View Post
              If you think their implemetation is not the same as Julia's, why not submit a patch?
              Because I have enough work to do submitting patches for actual features to software I actually use on top of my normal day job to spend time submitting improved benchmarks for software I don't use and don't particularly care about the benchmarks for. Again, performance is not my primary concern. Getting my work done is. And the performance of the glue language I use is not a major limiting factor for that.

              Originally posted by mmstick View Post
              In any case, C/C++/Python isn't nearly as convenient as Julia. Try doing these in the above:
              You can do that in python too, with the added benefit of not confusing function calls or numeric assignment with anonymous function assignment. Matlab made a similar mistake with confusing array indexing with function calls which led to no end of problems. I am disappointed to see Julia doing something similar. That sort of thing simply would not be allowed in python, since making sure the code is clear and unambiguous is a major concern.

              Whatever the case, those are all at least as easy in python:
              Code:
              # gratio returns the value of the golden ratio.
              gratio = lambda: (1 + 5**0.5) / 2
              # Or you could do the sane thing and just assign a float:
              gratio = (1 + 5**.5)/2
              
              # fib prints the Nth fibonacci number(s), also works for arrays
              fib = lambda n: (gratio**n - (1-gratio)**n) / 5**0.5
              
              # squared squares the input, also works for arrays
              squared = lambda x: x**2
              
              # average returns the average, also works for arrays
              average = lambda x: sum(x) / len(x)
              
              # digits returns the number of digits in the number.
              from math import trunc, log10
              digits = lambda x: trunc(log10(x)) + 1
              Now try doing this in Julia. Assume "readdata" is some arbitrary data-reading function. This will work on any platform with any directory separator:
              Code:
              import os
              from os.path import join, splitext
              # read all the data files in the directory and all subdirectories and store them in a dictionary (mapping) based on their path if their file extension is ".h5", if not skip them
              res = {}
              for path, _, filenames in os.walk('.'):
                  for fname in filenames:
                      if splitext(fname)[1] == ".h5":
                          fullname = join(path, fname)
                          res[fullname] = readdata(fullname)
              
              # or an equivalent, but less clear, one-liner
              res = {join(path, fname): readdata(join(path, fname)) for path, _, filenames in os.walk('.') for fname in filenames if splitext(fname)[1] == ".h5"}
              
              # or an anonymous function for an arbitrary directory and extension:
              res = lambda dirname, ext: {join(path, fname): readdata(join(path, fname)) for path, _, filenames in os.walk(dirname,) for fname in filenames if splitext(fname)[1] == ext}
              res('.', '.h5')
              Or what if you wanted to scrape data from tables on a web page? Or access data stored on an online resource like google docs? Or plot multiple interactive graphs where the dragging one plot or one marker also moved others? Or access multiple I/O bound tasks asynchronously? Despite your criticism of Python not being focused enough on numerical computing, these sorts of things are easy to do in Python specifically because it is explicitly designed and used as a general-purpose programming language. Things like advanced HTML handling, advanced network interfaces, advanced graphics toolkit interaction, and advanced asynchronous I/O handling were not created for numerical computing, and you don't see them on languages designed primarily for numerical computing, but people doing numerical computing benefit from work like this done for other purposes.
              TheBlackCat
              Senior Member
              Last edited by TheBlackCat; 22 October 2014, 06:18 AM.

              Comment


              • Originally posted by TheBlackCat View Post
                My point is that the one line example you gave does not do the same thing.
                of course it does

                Comment


                • Originally posted by mmstick View Post
                  1) You're really naive. Fortran is faster than C which is faster than C++. Julia makes heavy use of the best of C and Fortran math libraries so it is close to Fortran performance.
                  you are really stupid. c++ makes heavy use of the best of C and Fortran math libraries so it is close to Fortran performance(which is not 'much faster'. and plain c, being almost strict subset, is not faster at all). also native c++ can be faster than fortran.
                  Originally posted by mmstick View Post
                  2) That's not the point. C++ is an ugly bloated mess of inconsistency that only someone with years of experience can properly understand. In the real world, people prefer simplification over complification. C++ needs to die sooner rather than later. C++ certainly isn't made for scientific computing either, which Julia is.
                  in real world nobody uses julia but everyone uses c++. may be that is because everyone has different needs and toy one-purpose language doesn't cut it ?
                  Originally posted by mmstick View Post
                  3) Again, irrelevant. There's no need to rewrite the bulk of code when you can import an existing Fortran/C library which you are probably already using in another language. Not to mention, because writing your code in Julia is easier to read and write you have more time to work on optimizing your algorithms.
                  Again, irrelevant. real programs are not few lines wrappers around some fortran library
                  Originally posted by mmstick View Post
                  4) Then don't be a dumbass and learn about it.
                  i will be dumbass if i will learn about every of thousands of one-purpose toy languages

                  Comment


                  • Originally posted by pal666 View Post
                    of course it does
                    btw, isn't it funny that as soon, as you try to make fast python program, it turns out uglier than c++

                    Comment


                    • Originally posted by pal666 View Post
                      btw, isn't it funny that as soon, as you try to make fast python program, it turns out uglier than c++
                      Trying to do something "fast" in Python usually means implementing it in C or C++ and then wrapping it. So, I guess I could accept that it would be "at least as ugly as C++"

                      Comment

                      Working...
                      X