Announcement

Collapse
No announcement yet.

Julia Language v0.3 Improves Technical Computing

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

  • Julia Language v0.3 Improves Technical Computing

    Phoronix: Julia Language v0.3 Improves Technical Computing

    Version 0.3 of the Julia programming language has been released...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Julia is a language I'm keeping my eye on - it's meant for scientific computing but IMO it seems like a very good replacement for what I use Lua for.

    Comment


    • #3
      It really looks good and I'm using as a command line calculator.
      But when I really want high performance, I still use C =)

      Comment


      • #4
        Originally posted by souenzzo View Post
        It really looks good and I'm using as a command line calculator.
        But when I really want high performance, I still use C =)
        Aren't compiled languages like D much faster for high performance stuff?

        Comment


        • #5
          I dont know. I think fortran is the faster. But I prefer to code in C

          Comment


          • #6
            The problem Julia solves is not "fast programs for every task". It aims on one of the biggest problems of techinical computing today: the "many languages" problem. When doing numerical calculations one use Python or MATLAB, when doing text analysis one use Perl, when doing Statistics one use R, and so on. And when confronted with a slow inner loop? Move to C/Fortran.

            Julia has features that makes it good for every single one of these areas (and more areas that I didn't mention), while being very easy to learn and very fast. So when you use Julia you don't have to worry about inner loops being written in other language. Unless we're talking about Linear Algebra libs, full implememented in C/Fortran. But if you want to use Python or C/Fortran inside Julia, it's easy as hell, with very little glue code needed.

            Also, multiple dispatch allows you to choose the best function depending on the type of the parameters you passed at runtime. This makes easy to make high-performance specialized methods for each kind of data. The type system and the how easy it is to extend methods to new types make physical moddeling very neat. The metaprogramming is revealing itself very useful to me, on many contexts. Other thing you find very useful is the full support to UTF8 identifiers: the code ends up beign much more concise and readable.

            Comment


            • #7
              Originally posted by brk0_0 View Post
              The problem Julia solves is not "fast programs for every task". It aims on one of the biggest problems of techinical computing today: the "many languages" problem. When doing numerical calculations one use Python or MATLAB, when doing text analysis one use Perl, when doing Statistics one use R, and so on. And when confronted with a slow inner loop? Move to C/Fortran.

              Julia has features that makes it good for every single one of these areas (and more areas that I didn't mention), while being very easy to learn and very fast. So when you use Julia you don't have to worry about inner loops being written in other language. Unless we're talking about Linear Algebra libs, full implememented in C/Fortran. But if you want to use Python or C/Fortran inside Julia, it's easy as hell, with very little glue code needed.


              I am in technical computing, and I have never actually seen someone do the "many languages" thing. I know people who use python, people who use perl, people who use matlab, people who use igor. But although it is talked about as the ideal, using multiple languages doesn't seem to be common in practice. That is why things like pandas exist.
              Last edited by TheBlackCat; 24 August 2014, 05:50 PM.

              Comment


              • #8
                Originally posted by TheBlackCat View Post


                I am in technical computing, and I have never actually seen someone do the "many languages" thing. I know people who use python, people who use perl, people who use matlab, people who use igor. But although it is talked about as the ideal, using multiple languages doesn't seem to be common in practice. That is why things like pandas exist.
                Well, maybe it's just me, but the many languages thing is common around here. R is used in the same lab as Python, doing somewhat related tasks. The same goes with MATLAB. But the true problem is the amount of code done in C/Fortran: many time, simple but demanding tasks need to be done in a faster language, resulting in less readable/maintanable code, lots of glue, and a break on the workflow (compile, etc.).

                Julia pretty much delivers: DataFrames are shapping up as an alternative to Pandas/R, and the built-in linear algebra/statustics functionality are very usable. A few things are more satisfying than writing programs with a syntax close to Python and ending up with a much better performance. Also, the REPL and IJulia notebook are awesome tools.

                Comment


                • #9
                  Originally posted by brk0_0 View Post
                  R is used in the same lab as Python, doing somewhat related tasks. The same goes with MATLAB.
                  Yes, individual people use individual languages, but at least in my experience very few people are using multiple languages at the same time. And people generally aren't using them because they are absolutely optimal, they are using them because they are familiar and they consider the time cost of learning a new language too high. Julia makes things worse in this regard, as the comic points out. Instead of 5 languages that making sharing work more difficult, now there are 6. Julia may be bale to run code from other languages, but the opposite is not true.

                  Originally posted by brk0_0 View Post
                  But the true problem is the amount of code done in C/Fortran: many time, simple but demanding tasks need to be done in a faster language, resulting in less readable/maintanable code, lots of glue, and a break on the workflow (compile, etc.).
                  Yes, but there is a lot of work going on in improving that situation in other languages such as python. Julia has a very dedicated community, but right now it is a pretty small community. It remains to be seen whether it can attract a large enough community to make it competitive with, say, pypy, especially when corporate support seems more interested in improving performance of existing languages rather than switching to a new one. My distribution of choice, openSUSE, packaged pypy a good year before they packaged Julia.

                  Originally posted by brk0_0 View Post
                  Julia pretty much delivers: DataFrames are shapping up as an alternative to Pandas/R, and the built-in linear algebra/statustics functionality are very usable. A few things are more satisfying than writing programs with a syntax close to Python and ending up with a much better performance. Also, the REPL and IJulia notebook are awesome tools.
                  First, Julia syntax isn't very close to python at all. It is much more similar to matlab, actually, it just fixes a few of the most bone-headed flaws in matlab.

                  Second, yes, Julia is making progress on these areas, and its developers are clearly dedicated and working hard, but it is an uphill battle. They are trying to play catch-up to moving targets, moving targets that in most cases are years ahead and have significantly larger pools of contributors. That is not to say they can't do it, and it definitely is not to say they shouldn't do it, but we need to be realistic. Julia is going to live or die based on the size and quality of its community. The quality is certainly excellent in this case, but it is still relatively small, and the nice it is trying to fill is also aiming to being filled by more established languages.

                  Personally, I am watching Julia closely. It is a project with a lot of promise. But given the small community, the small number of available packages, the relative lack of maturity, and the fact that python projects are aiming to fill the same niche and doing so with what seems to be roughly similar speed, I currently don't see an advantage to investing time in switching at this point. I feel right now that, like in the numeric days with arrays, python developers are exploring different ways to improve performance. But eventually they are going to converge on a single solution. If they do that before Julia can really establish itself, Julia may find itself without a niche to fill.
                  Last edited by TheBlackCat; 25 August 2014, 06:13 AM.

                  Comment


                  • #10
                    Originally posted by TheBlackCat View Post
                    Yes, individual people use individual languages, but at least in my experience very few people are using multiple languages at the same time. And people generally aren't using them because they are absolutely optimal, they are using them because they are familiar and they consider the time cost of learning a new language too high. Julia makes things worse in this regard, as the comic points out. Instead of 5 languages that making sharing work more difficult, now there are 6. Julia may be bale to run code from other languages, but the opposite is not true.


                    Yes, but there is a lot of work going on in improving that situation in other languages such as python. Julia has a very dedicated community, but right now it is a pretty small community. It remains to be seen whether it can attract a large enough community to make it competitive with, say, pypy, especially when corporate support seems more interested in improving performance of existing languages rather than switching to a new one. My distribution of choice, openSUSE, packaged pypy a good year before they packaged Julia.


                    First, Julia syntax isn't very close to python at all. It is much more similar to matlab, actually, it just fixes a few of the most bone-headed flaws in matlab.

                    Second, yes, Julia is making progress on these areas, and its developers are clearly dedicated and working hard, but it is an uphill battle. They are trying to play catch-up to moving targets, moving targets that in most cases are years ahead and have significantly larger pools of contributors. That is not to say they can't do it, and it definitely is not to say they shouldn't do it, but we need to be realistic. Julia is going to live or die based on the size and quality of its community. The quality is certainly excellent in this case, but it is still relatively small, and the nice it is trying to fill is also aiming to being filled by more established languages.

                    Personally, I am watching Julia closely. It is a project with a lot of promise. But given the small community, the small number of available packages, the relative lack of maturity, and the fact that python projects are aiming to fill the same niche and doing so with what seems to be roughly similar speed, I currently don't see an advantage to investing time in switching at this point. I feel right now that, like in the numeric days with arrays, python developers are exploring different ways to improve performance. But eventually they are going to converge on a single solution. If they do that before Julia can really establish itself, Julia may find itself without a niche to fill.

                    Again, the use of C/Fortran at the same time with other languages is not small. Everyone in thecnical computing is aware of this problem. My point was, when you have a language prepared to accomplish many tasks in one field, maybe it makes collaboration easier. Ok, just maybe, but that's a good thing anyway. Also, I consider the effort to learn Julia (well enough to write some numerical stuff) not to high when you come from MATLAB/Python.

                    PyPy isn't as fast as Julia as you claim. Today, PyPys project is 7 years old, with the Psycho JIT compiler (2002) beign the seed of its development. It's a very mature project, and much older than Julia, but it's still slower:


                    Julia is a new statistical programming language that claims significantly better performance than competing languages. I'm trying to verify this. Julia has a performance test written in Python: h...


                    The full optimization of the parser/compiler from Julia has not even started. The language is just shaping up (v0.3) and it's 3x-10x faster than the mature PyPy. Python, I fear, is slow by design. It's type system is slow, the abstraction layers, and much more, makes Julia like optimization very hard (but I don't know the details, and maybe I am wrong, but that's what I fear). The duck typing is also bad for performance, and Julia also solves this problem in a very neat way. And, for me, it's syntax borrows from both Python and MATLAB. Best of both worlds, and with a LISP touch.

                    Here is the thing, the devs are not competing with PyPy, they are competing with Fortran and C. And for a dynamic language like Julia, it's pretty impressive to have, sometime, better velocity than both, even if it's just a microbenchmark.

                    Remember, R was slow and steady with its popularity. It was certainly not a boom, and its packages were not available from day one. The syntax were not familiar, and it isn't too easy to pick up (compared to MATLAB and Python). But it worked very well. I would say Julia, with 2 years old, has a good amount of packages already, with a good community working on them. This may be an uphill battle, but Julia delivers today what it promisses, even if it's not close to finished.

                    Comment

                    Working...
                    X