3 ms·

> do not play nice with other python libraries. Julia hasn't been around long enough to build ecosystem with multiple commerical giants building competing prod

> do not play nice with other python libraries. Julia hasn't been around long enough to build ecosystem with multiple commerical giants building competing products. > Julia does not make that sacrifice. Sure, Julia sacrifices your sanity on the alter of stack traces, method resolution, time to first plot, among others. > fairly limited subset of python Fantastic comment, always brought up, except that this same subset of Python (really how to use CPU efficiently) is about the same that anyone writing about Julia performance is preaching.

DNF2 6y ago
I beg your pardon. What parts of Julia are not supported by its jit compiler?
krastanov 6y ago
I think a really good example of how Julian tools are composable and work with the whole of the language, while that is not the case with Pythonic tools, is autodifferentiation. The many different julian autodiff libraries have little trouble performing the autodiff through special functions, weird data structures, and 3rd party libraries. In python, none of the autodiff tools play nice with scipy or with mpmath or with sympy (or qutip, which is something I need). This is not about commercial competitors either - all of the libraries I mentioned are non-commercial. Julia provides the interoperability between such libraries, including custom datatypes, frequently with fast zero-cost abstractions.
- marmaduke 6y ago
  I agree but think that Julia had the benefit of watching Python and MATLAB suck at auto diff and do better as a community. That said PyTorch and Jax are great. > fast zero-cost abstraction Until you get a compiler error and the stack trace takes up a few screens of text. Who maintains that abstraction by the way? Nothing is free.
amkkma 6y ago
>Fantastic comment, always brought up, except that this same >subset of Python (really how to use CPU efficiently) is ?about the same that anyone writing about Julia performance is >preaching. This is completely and demonstrably false. Julia allows fast programming with macros, multiple dispatch, abstract types and more.
- marmaduke 6y ago
  All those features have a cost that, in a performance oriented setting, require restricted the code to a subset of Julia that matches what the hardware is fast at.
  - deleted 6y ago
    [deleted]
  - dklend122 6y ago
    No, that's not true. I specifically mentioned features that can easily be made zero cost on both CPU and GPU targets. In fact, those aren't special features and there is no other subset. Those are the core abstractions on which everything in Julia, down to primitive types and wrappers for llvm intrinsics are built. Without them you wouldn't have Julia. Julia's GPU ecosystem wouldn't be where it is with just one or two people maintaining it without being able to reuse those features to plug into existing machinery.
  - DNF2 6y ago
    Where are you getting this from? None of those features have a performance cost, if used according to some simple guidelines. In fact, multiple dispatch is essential to get good performance, abstract types have a cost if explicitly used inside struct definitions, but that's why you use parametric types, and abstract types do not have a cost in function signatures. Macros are expanded at compile-time, and at least have no runtime cost, in fact they are often used for improved performance. I think there's some fundamental misunderstanding going on here, but I'm not sure what it is. Or do you mean to say that if it is possible to write slow code in a language, then only a subset of that language has good performance? If that is the case, I don't know how to respond.

DNF2 6y ago

I beg your pardon. What parts of Julia are not supported by its jit compiler?

krastanov 6y ago

I think a really good example of how Julian tools are composable and work with the whole of the language, while that is not the case with Pythonic tools, is autodifferentiation. The many different julian autodiff libraries have little trouble performing the autodiff through special functions, weird data structures, and 3rd party libraries. In python, none of the autodiff tools play nice with scipy or with mpmath or with sympy (or qutip, which is something I need). This is not about commercial competitors either - all of the libraries I mentioned are non-commercial. Julia provides the interoperability between such libraries, including custom datatypes, frequently with fast zero-cost abstractions.

marmaduke 6y ago
I agree but think that Julia had the benefit of watching Python and MATLAB suck at auto diff and do better as a community. That said PyTorch and Jax are great. > fast zero-cost abstraction Until you get a compiler error and the stack trace takes up a few screens of text. Who maintains that abstraction by the way? Nothing is free.

amkkma 6y ago

>Fantastic comment, always brought up, except that this same >subset of Python (really how to use CPU efficiently) is ?about the same that anyone writing about Julia performance is >preaching. This is completely and demonstrably false. Julia allows fast programming with macros, multiple dispatch, abstract types and more.

marmaduke 6y ago
All those features have a cost that, in a performance oriented setting, require restricted the code to a subset of Julia that matches what the hardware is fast at.
- deleted 6y ago
  [deleted]
- dklend122 6y ago
  No, that's not true. I specifically mentioned features that can easily be made zero cost on both CPU and GPU targets. In fact, those aren't special features and there is no other subset. Those are the core abstractions on which everything in Julia, down to primitive types and wrappers for llvm intrinsics are built. Without them you wouldn't have Julia. Julia's GPU ecosystem wouldn't be where it is with just one or two people maintaining it without being able to reuse those features to plug into existing machinery.
- DNF2 6y ago
  Where are you getting this from? None of those features have a performance cost, if used according to some simple guidelines. In fact, multiple dispatch is essential to get good performance, abstract types have a cost if explicitly used inside struct definitions, but that's why you use parametric types, and abstract types do not have a cost in function signatures. Macros are expanded at compile-time, and at least have no runtime cost, in fact they are often used for improved performance. I think there's some fundamental misunderstanding going on here, but I'm not sure what it is. Or do you mean to say that if it is possible to write slow code in a language, then only a subset of that language has good performance? If that is the case, I don't know how to respond.