www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Julia vs. D?

reply "Chris" <wendlec tcd.ie> writes:
I recently came across this article 
http://www.wired.com/2014/02/julia/. On the Julia homepage there 
are some benchmarks times relative to C. I know that bearophile 
has mentioned Julia several times on this forum. Has anyone 
compared D's vs Julia's performance as well as design features?
May 06 2014
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Tuesday, 6 May 2014 at 09:11:30 UTC, Chris wrote:

 I recently came across this article 
 http://www.wired.com/2014/02/julia/. On the Julia homepage 
 there are some benchmarks times relative to C. I know that 
 bearophile has mentioned Julia several times on this forum. Has 
 anyone compared D's vs Julia's performance as well as design 
 features?


I can only comment on design features.

You can think of Julia as a dynamic language similar to Python, 
with optional typing and for such a young language, a quite good 
JIT compiler backed by the LLVM backend.

It is a multi-paradigm language, with an OO approach based on 
multi-methods and direct support for scientific programming.

The target audience are the scientifc community that makes use of 
R, Python with NumPy and so on, which are currently disappointed 
with the performance of said systems. Their goal is to keep the 
programming flexibility of R and Python, while improving the 
performance without having to be forced to write C code.

--
Paulo
May 06 2014
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Paulo Pinto:


 You can think of Julia as a dynamic language similar to Python, 
 with optional typing and for such a young language, a quite 
 good JIT compiler backed by the LLVM backend.


Unlike dynamic languages, at running time all variables are 
strongly typed.

Bye,
bearophile
May 06 2014
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 5/6/14, 8:23 AM, bearophile wrote:

 Paulo Pinto:


 You can think of Julia as a dynamic language similar to Python, with
 optional typing and for such a young language, a quite good JIT
 compiler backed by the LLVM backend.


 Unlike dynamic languages, at running time all variables are strongly typed.


What do you mean?
May 06 2014
parent reply "Chris" <wendlec tcd.ie> writes:
On Tuesday, 6 May 2014 at 13:25:56 UTC, Ary Borenszweig wrote:

 On 5/6/14, 8:23 AM, bearophile wrote:

 Paulo Pinto:


 You can think of Julia as a dynamic language similar to 
 Python, with
 optional typing and for such a young language, a quite good 
 JIT
 compiler backed by the LLVM backend.


 Unlike dynamic languages, at running time all variables are 
 strongly typed.


 What do you mean?


Just a wild guess: that the compiler infers the type of a 
variable and turns it into a static type. That would increase the 
security during runtime (plugins, libraries, crackers).
May 06 2014
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Chris:


 That would increase the security during runtime (plugins, 
 libraries, crackers).


Yes, and also gives almost native performance.

Bye,
bearophile
May 06 2014
parent reply Dejan Lekic <dejan.lekic gmail.com> writes:
bearophile wrote:


 Chris:
 

 That would increase the security during runtime (plugins,
 libraries, crackers).


 
 Yes, and also gives almost native performance.
 
 Bye,
 bearophile


One can argue that every modern JIT achieves "almost native performance" ...

-- 
http://dejan.lekic.org
May 06 2014
parent "bearophile" <bearophileHUGS lycos.com> writes:
Dejan Lekic:


 One can argue that every modern JIT achieves "almost native 
 performance" ...


OK. Then for Julia remove the "almost" :-)

Bye,
bearophile
May 06 2014
prev sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 5/6/14, 10:41 AM, Chris wrote:

 On Tuesday, 6 May 2014 at 13:25:56 UTC, Ary Borenszweig wrote:

 On 5/6/14, 8:23 AM, bearophile wrote:

 Paulo Pinto:


 You can think of Julia as a dynamic language similar to Python, with
 optional typing and for such a young language, a quite good JIT
 compiler backed by the LLVM backend.


 Unlike dynamic languages, at running time all variables are strongly
 typed.


 What do you mean?


 Just a wild guess: that the compiler infers the type of a variable and
 turns it into a static type. That would increase the security during
 runtime (plugins, libraries, crackers).


Julia doesn't have a compiler. There's no compile-time and run-time 
distinction. But functions are jitted before execution.

I don't see how that means "variables are strongly typed". If you mean 
that at runtime they carry their type information, so do dynamic languages.
May 06 2014
parent reply "Chris" <wendlec tcd.ie> writes:
On Tuesday, 6 May 2014 at 17:10:39 UTC, Ary Borenszweig wrote:

 On 5/6/14, 10:41 AM, Chris wrote:

 On Tuesday, 6 May 2014 at 13:25:56 UTC, Ary Borenszweig wrote:

 On 5/6/14, 8:23 AM, bearophile wrote:

 Paulo Pinto:


 You can think of Julia as a dynamic language similar to 
 Python, with
 optional typing and for such a young language, a quite good 
 JIT
 compiler backed by the LLVM backend.


 Unlike dynamic languages, at running time all variables are 
 strongly
 typed.


 What do you mean?


 Just a wild guess: that the compiler infers the type of a 
 variable and
 turns it into a static type. That would increase the security 
 during
 runtime (plugins, libraries, crackers).


 Julia doesn't have a compiler. There's no compile-time and 
 run-time distinction. But functions are jitted before execution.


I know. I was talking about JIT compilation. There must be some 
kind of (jit) compiler.


 I don't see how that means "variables are strongly typed". If 
 you mean that at runtime they carry their type information, so 
 do dynamic languages.


But are the types immutable at runtime (in other dynamically 
typed languages) or can they be reassigned as in

x =  "Hello"
x = 5

If yes, then I think this is what Julia is addressing, that a 
module, library or malevolent cracker cannot reassign a different 
type to a variable.

x = 5 // Error!
If so,
May 06 2014
parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 06.05.2014 22:44, schrieb Chris:

 On Tuesday, 6 May 2014 at 17:10:39 UTC, Ary Borenszweig wrote:

 On 5/6/14, 10:41 AM, Chris wrote:

 On Tuesday, 6 May 2014 at 13:25:56 UTC, Ary Borenszweig wrote:

 On 5/6/14, 8:23 AM, bearophile wrote:

 Paulo Pinto:


 You can think of Julia as a dynamic language similar to Python, with
 optional typing and for such a young language, a quite good JIT
 compiler backed by the LLVM backend.


 Unlike dynamic languages, at running time all variables are strongly
 typed.


 What do you mean?


 Just a wild guess: that the compiler infers the type of a variable and
 turns it into a static type. That would increase the security during
 runtime (plugins, libraries, crackers).


 Julia doesn't have a compiler. There's no compile-time and run-time
 distinction. But functions are jitted before execution.


 I know. I was talking about JIT compilation. There must be some kind of
 (jit) compiler.


 I don't see how that means "variables are strongly typed". If you mean
 that at runtime they carry their type information, so do dynamic
 languages.


 But are the types immutable at runtime (in other dynamically typed
 languages) or can they be reassigned as in

 x =  "Hello"
 x = 5

 If yes, then I think this is what Julia is addressing, that a module,
 library or malevolent cracker cannot reassign a different type to a
 variable.

 x = 5 // Error!
 If so,


They can be re-assigned (http://forio.com/julia/repl/):

julia> x = "Hello"
"Hello"
julia> x = 5
5
julia>

Julia compiler works in a similar way to Self, Strongtalk, Dylan, Lisp 
and so on.

The language is dynamic, with optional type annotations and the compiler 
does its best to infer the types.

The design of the language is done in a JIT friendly way, while keeping 
its dynamic capabilities.


--
Paulo
May 06 2014
next sibling parent "Chris" <wendlec tcd.ie> writes:
On Tuesday, 6 May 2014 at 20:52:20 UTC, Paulo Pinto wrote:

 Am 06.05.2014 22:44, schrieb Chris:

 On Tuesday, 6 May 2014 at 17:10:39 UTC, Ary Borenszweig wrote:

 On 5/6/14, 10:41 AM, Chris wrote:

 On Tuesday, 6 May 2014 at 13:25:56 UTC, Ary Borenszweig 
 wrote:

 On 5/6/14, 8:23 AM, bearophile wrote:

 Paulo Pinto:


 You can think of Julia as a dynamic language similar to 
 Python, with
 optional typing and for such a young language, a quite 
 good JIT
 compiler backed by the LLVM backend.


 Unlike dynamic languages, at running time all variables 
 are strongly
 typed.


 What do you mean?


 Just a wild guess: that the compiler infers the type of a 
 variable and
 turns it into a static type. That would increase the 
 security during
 runtime (plugins, libraries, crackers).


 Julia doesn't have a compiler. There's no compile-time and 
 run-time
 distinction. But functions are jitted before execution.


 I know. I was talking about JIT compilation. There must be 
 some kind of
 (jit) compiler.


 I don't see how that means "variables are strongly typed". If 
 you mean
 that at runtime they carry their type information, so do 
 dynamic
 languages.


 But are the types immutable at runtime (in other dynamically 
 typed
 languages) or can they be reassigned as in

 x =  "Hello"
 x = 5

 If yes, then I think this is what Julia is addressing, that a 
 module,
 library or malevolent cracker cannot reassign a different type 
 to a
 variable.

 x = 5 // Error!
 If so,


 They can be re-assigned (http://forio.com/julia/repl/):

 julia> x = "Hello"
 "Hello"
 julia> x = 5
 5
 julia>

 Julia compiler works in a similar way to Self, Strongtalk, 
 Dylan, Lisp and so on.

 The language is dynamic, with optional type annotations and the 
 compiler does its best to infer the types.

 The design of the language is done in a JIT friendly way, while 
 keeping its dynamic capabilities.


 --
 Paulo


So what's the point then? To have the program crash at runtime or 
better jit-time when the types are not assigned correctly? Then 
again, if types can be changed dynamically, how can the jit 
compiler say it's "wrong"? Or is there something I've missed?
May 06 2014
prev sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Paulo Pinto:


 They can be re-assigned (http://forio.com/julia/repl/):

 julia> x = "Hello"
 "Hello"
 julia> x = 5
 5
 julia>


I think the JIT compiler splits those two in two different 
variables :-)



 The language is dynamic,


The language tries its best to be flexible as a dynamic language. 
But variables never carry a run-time type tag, unlike in Lisp.

Bye,
bearophile
May 06 2014
next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 06.05.2014 23:00, schrieb bearophile:

 Paulo Pinto:


 They can be re-assigned (http://forio.com/julia/repl/):

 julia> x = "Hello"
 "Hello"
 julia> x = 5
 5
 julia>


 I think the JIT compiler splits those two in two different variables :-)



 The language is dynamic,


 The language tries its best to be flexible as a dynamic language. But
 variables never carry a run-time type tag, unlike in Lisp.

 Bye,
 bearophile


That is an implementation detail I would say, but then again I only saw 
a few talks online and have not played that much with it.

--
Paulo
May 06 2014
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Paulo Pinto:


 That is an implementation detail I would say,


It's not an implementation detail, it has consequences on the 
kind of code you are allowed to write, because it's not really a 
dynamic language.  After the JIT compilation it's "statically" 
typed, with some niceties like the type splitting you have seen 
with the x variable. In Julia you can't write all the programs 
you can write in Python. But in practice the limitations are not 
a problem for the scientific code, and the advantages are great.

Bye,
bearophile
May 06 2014
next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Tuesday, 6 May 2014 at 21:31:32 UTC, bearophile wrote:

 Paulo Pinto:


 That is an implementation detail I would say,


 It's not an implementation detail, it has consequences on the 
 kind of code you are allowed to write, because it's not really 
 a dynamic language.  After the JIT compilation it's 
 "statically" typed, with some niceties like the type splitting 
 you have seen with the x variable. In Julia you can't write all 
 the programs you can write in Python. But in practice the 
 limitations are not a problem for the scientific code, and the 
 advantages are great.

 Bye,
 bearophile


Maybe we are talking across each other, but JIT code is always 
statically typed after native code generation.

The approach taken by Julia is no different than other dynamic 
languages that enjoy AOT native compilers.

If you mean Julia allows for less dynamic programming cleverness 
as Python, there I agree with you.

I guess I need to play more with it, maybe then I can better 
grasp what you mean.

--
Paulo
May 06 2014
prev sibling parent "Chris" <wendlec tcd.ie> writes:
On Tuesday, 6 May 2014 at 21:31:32 UTC, bearophile wrote:

 Paulo Pinto:


 That is an implementation detail I would say,


 It's not an implementation detail, it has consequences on the 
 kind of code you are allowed to write, because it's not really 
 a dynamic language.  After the JIT compilation it's 
 "statically" typed, with some niceties like the type splitting 
 you have seen with the x variable. In Julia you can't write all 
 the programs you can write in Python. But in practice the 
 limitations are not a problem for the scientific code, and the 
 advantages are great.

 Bye,
 bearophile


So this basically means:

setName(name)
   userName = name;  // string type

extern module / cracker:

setName(5.0)  // Error or at least doesn't affect original 
userName

Right or wrong?
May 07 2014
prev sibling parent reply "Mason McGill" <mmcgill caltech.edu> writes:
On Tuesday, 6 May 2014 at 21:00:18 UTC, bearophile wrote:

 The language tries its best to be flexible as a dynamic 
 language. But variables never carry a run-time type tag, unlike 
 in Lisp.


Hmm... Then how can I do this:

   x = 5

   x = 5.0


?

Is Julia doing something trickier than I think it is? Or do you 
just mean they don't carry type tags after compilation?
May 07 2014
parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Wednesday, 7 May 2014 at 07:27:42 UTC, Mason McGill wrote:

 On Tuesday, 6 May 2014 at 21:00:18 UTC, bearophile wrote:

 The language tries its best to be flexible as a dynamic 
 language. But variables never carry a run-time type tag, 
 unlike in Lisp.


 Hmm... Then how can I do this:

   x = 5

   x = 5.0


 ?

 Is Julia doing something trickier than I think it is? Or do you 
 just mean they don't carry type tags after compilation?


Maybe the first x stops existing, and a new one is created on 
reassignment?

A more interesting case is this (pseudo code, don't know Julia 
syntax):

     x = 5
     if (...) {
         x = "Hello"
     }


Is that disallowed?
May 07 2014
parent Ary Borenszweig <ary esperanto.org.ar> writes:
On 5/7/14, 6:18 AM, "Marc Schütz" <schuetzm gmx.net>" wrote:

 On Wednesday, 7 May 2014 at 07:27:42 UTC, Mason McGill wrote:

 On Tuesday, 6 May 2014 at 21:00:18 UTC, bearophile wrote:

 The language tries its best to be flexible as a dynamic language. But
 variables never carry a run-time type tag, unlike in Lisp.


 Hmm... Then how can I do this:

   x = 5

   x = 5.0


 ?

 Is Julia doing something trickier than I think it is? Or do you just
 mean they don't carry type tags after compilation?


 Maybe the first x stops existing, and a new one is created on reassignment?

 A more interesting case is this (pseudo code, don't know Julia syntax):

      x = 5
      if (...) {
          x = "Hello"
      }


 Is that disallowed?


I just tried it. I also used the code_llvm function to see what llvm is 
generated. Some lines:

%8 = call %jl_value_t*  jl_box_int32(i32 %0), !dbg !4339

(an int is being boxed and you get a pointer to a jl_value_t)

   %13 = call %jl_value_t*  jl_apply_generic(%jl_value_t* inttoptr (i64 
4373507136 to %jl_value_t*), %jl_value_t** %6, i32 2), !dbg !4346

(a generic function call is being made)

So, there clearly must be runtime information associated to the 
variables, at least when they need boxing or this kind of multi-dispatch 
at runtime.
May 07 2014
prev sibling next sibling parent reply "Chris" <wendlec tcd.ie> writes:
On Tuesday, 6 May 2014 at 11:20:33 UTC, Paulo Pinto wrote:

 On Tuesday, 6 May 2014 at 09:11:30 UTC, Chris wrote:

 I recently came across this article 
 http://www.wired.com/2014/02/julia/. On the Julia homepage 
 there are some benchmarks times relative to C. I know that 
 bearophile has mentioned Julia several times on this forum. 
 Has anyone compared D's vs Julia's performance as well as 
 design features?


 I can only comment on design features.

 You can think of Julia as a dynamic language similar to Python, 
 with optional typing and for such a young language, a quite 
 good JIT compiler backed by the LLVM backend.

 It is a multi-paradigm language, with an OO approach based on 
 multi-methods and direct support for scientific programming.

 The target audience are the scientifc community that makes use 
 of R, Python with NumPy and so on, which are currently 
 disappointed with the performance of said systems. Their goal 
 is to keep the programming flexibility of R and Python, while 
 improving the performance without having to be forced to write 
 C code.

 --
 Paulo


Maybe it's time to think about a D interface to Julia. If Julia 
catches on within the scientific community, it would be good to 
have a foot in the door. Science quickly creates large code 
bases, unfortunately, so far it's mostly Python and Matlab which 
makes it hard to use the algorithms in real world applications.
May 06 2014
parent reply "Mason McGill" <mmcgill caltech.edu> writes:
On Tuesday, 6 May 2014 at 11:28:21 UTC, Chris wrote:

 Maybe it's time to think about a D interface to Julia. If Julia 
 catches on within the scientific community, it would be good to 
 have a foot in the door. Science quickly creates large code 
 bases, unfortunately, so far it's mostly Python and Matlab 
 which makes it hard to use the algorithms in real world 
 applications.


I've actually been working on just that, on and off for a few 
months now. Such a thing is kind of "anti-Julian", though, since 
one of Julia's main goals is to reduce or eliminate the need for 
mixed-language projects.

However, with D, you can compile small shared libraries that can 
be automatically bound to your users' favorite dynamic runtimes 
(via compile-time reflection). I'm hoping this will be good for 
both D and Julia, allowing library developers to reach a broader 
audience, and library consumers greater flexibility.

I'll post on the D "announce" thread when I have something 
working, and I'd definitely appreciate tests/bug-reports at that 
time!
May 06 2014
parent reply "Chris" <wendlec tcd.ie> writes:
On Tuesday, 6 May 2014 at 23:19:47 UTC, Mason McGill wrote:

 On Tuesday, 6 May 2014 at 11:28:21 UTC, Chris wrote:

 Maybe it's time to think about a D interface to Julia. If 
 Julia catches on within the scientific community, it would be 
 good to have a foot in the door. Science quickly creates large 
 code bases, unfortunately, so far it's mostly Python and 
 Matlab which makes it hard to use the algorithms in real world 
 applications.


 I've actually been working on just that, on and off for a few 
 months now. Such a thing is kind of "anti-Julian", though, 
 since one of Julia's main goals is to reduce or eliminate the 
 need for mixed-language projects.

 However, with D, you can compile small shared libraries that 
 can be automatically bound to your users' favorite dynamic 
 runtimes (via compile-time reflection). I'm hoping this will be 
 good for both D and Julia, allowing library developers to reach 
 a broader audience, and library consumers greater flexibility.

 I'll post on the D "announce" thread when I have something 
 working, and I'd definitely appreciate tests/bug-reports at 
 that time!


I was also thinking in the direction of enabling D to use 
existing Julia code seamlessly, so you can just call it from D 
(extern(J)), and maybe even efficiently compile it into binaries 
along with D code, as you would with extern(C) calls now.
May 07 2014
next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Wednesday, 7 May 2014 at 09:16:01 UTC, Chris wrote:

 On Tuesday, 6 May 2014 at 23:19:47 UTC, Mason McGill wrote:

 On Tuesday, 6 May 2014 at 11:28:21 UTC, Chris wrote:

 Maybe it's time to think about a D interface to Julia. If 
 Julia catches on within the scientific community, it would be 
 good to have a foot in the door. Science quickly creates 
 large code bases, unfortunately, so far it's mostly Python 
 and Matlab which makes it hard to use the algorithms in real 
 world applications.


 I've actually been working on just that, on and off for a few 
 months now. Such a thing is kind of "anti-Julian", though, 
 since one of Julia's main goals is to reduce or eliminate the 
 need for mixed-language projects.

 However, with D, you can compile small shared libraries that 
 can be automatically bound to your users' favorite dynamic 
 runtimes (via compile-time reflection). I'm hoping this will 
 be good for both D and Julia, allowing library developers to 
 reach a broader audience, and library consumers greater 
 flexibility.

 I'll post on the D "announce" thread when I have something 
 working, and I'd definitely appreciate tests/bug-reports at 
 that time!


 I was also thinking in the direction of enabling D to use 
 existing Julia code seamlessly, so you can just call it from D 
 (extern(J)), and maybe even efficiently compile it into 
 binaries along with D code, as you would with extern(C) calls 
 now.


That would be very good. If julia is to become a/the norm for 
scientific computing, D could form the full-power 
systems/applications partner very neatly.
May 07 2014
prev sibling parent reply "bachmeier" <no spam.net> writes:
On Wednesday, 7 May 2014 at 09:16:01 UTC, Chris wrote:

 On Tuesday, 6 May 2014 at 23:19:47 UTC, Mason McGill wrote:

 On Tuesday, 6 May 2014 at 11:28:21 UTC, Chris wrote:

 Maybe it's time to think about a D interface to Julia. If 
 Julia catches on within the scientific community, it would be 
 good to have a foot in the door. Science quickly creates 
 large code bases, unfortunately, so far it's mostly Python 
 and Matlab which makes it hard to use the algorithms in real 
 world applications.


 I've actually been working on just that, on and off for a few 
 months now. Such a thing is kind of "anti-Julian", though, 
 since one of Julia's main goals is to reduce or eliminate the 
 need for mixed-language projects.

 However, with D, you can compile small shared libraries that 
 can be automatically bound to your users' favorite dynamic 
 runtimes (via compile-time reflection). I'm hoping this will 
 be good for both D and Julia, allowing library developers to 
 reach a broader audience, and library consumers greater 
 flexibility.

 I'll post on the D "announce" thread when I have something 
 working, and I'd definitely appreciate tests/bug-reports at 
 that time!


 I was also thinking in the direction of enabling D to use 
 existing Julia code seamlessly, so you can just call it from D 
 (extern(J)), and maybe even efficiently compile it into 
 binaries along with D code, as you would with extern(C) calls 
 now.


It's really easy to do that with R. There is a package RInside 
that makes it trivial to embed R in a C++ program, and it's not 
difficult to use with D.
May 07 2014
parent reply "Chris" <wendlec tcd.ie> writes:
On Wednesday, 7 May 2014 at 12:05:10 UTC, bachmeier wrote:

 On Wednesday, 7 May 2014 at 09:16:01 UTC, Chris wrote:

 On Tuesday, 6 May 2014 at 23:19:47 UTC, Mason McGill wrote:

 On Tuesday, 6 May 2014 at 11:28:21 UTC, Chris wrote:

 Maybe it's time to think about a D interface to Julia. If 
 Julia catches on within the scientific community, it would 
 be good to have a foot in the door. Science quickly creates 
 large code bases, unfortunately, so far it's mostly Python 
 and Matlab which makes it hard to use the algorithms in real 
 world applications.


 I've actually been working on just that, on and off for a few 
 months now. Such a thing is kind of "anti-Julian", though, 
 since one of Julia's main goals is to reduce or eliminate the 
 need for mixed-language projects.

 However, with D, you can compile small shared libraries that 
 can be automatically bound to your users' favorite dynamic 
 runtimes (via compile-time reflection). I'm hoping this will 
 be good for both D and Julia, allowing library developers to 
 reach a broader audience, and library consumers greater 
 flexibility.

 I'll post on the D "announce" thread when I have something 
 working, and I'd definitely appreciate tests/bug-reports at 
 that time!


 I was also thinking in the direction of enabling D to use 
 existing Julia code seamlessly, so you can just call it from D 
 (extern(J)), and maybe even efficiently compile it into 
 binaries along with D code, as you would with extern(C) calls 
 now.


 It's really easy to do that with R. There is a package RInside 
 that makes it trivial to embed R in a C++ program, and it's not 
 difficult to use with D.


Would be cool if we had something like this for Julia (if it 
really catches on).
May 07 2014
parent reply "Laeeth Isharc" <Laeeth.nospam nospam-laeeth.com> writes:
On Wednesday, 7 May 2014 at 14:57:36 UTC, Chris wrote:

 On Wednesday, 7 May 2014 at 12:05:10 UTC, bachmeier wrote:

 On Wednesday, 7 May 2014 at 09:16:01 UTC, Chris wrote:

 On Tuesday, 6 May 2014 at 23:19:47 UTC, Mason McGill wrote:

 On Tuesday, 6 May 2014 at 11:28:21 UTC, Chris wrote:

 Maybe it's time to think about a D interface to Julia. If 
 Julia catches on within the scientific community, it would 
 be good to have a foot in the door. Science quickly creates 
 large code bases, unfortunately, so far it's mostly Python 
 and Matlab which makes it hard to use the algorithms in 
 real world applications.


 I've actually been working on just that, on and off for a 
 few months now. Such a thing is kind of "anti-Julian", 
 though, since one of Julia's main goals is to reduce or 
 eliminate the need for mixed-language projects.

 However, with D, you can compile small shared libraries that 
 can be automatically bound to your users' favorite dynamic 
 runtimes (via compile-time reflection). I'm hoping this will 
 be good for both D and Julia, allowing library developers to 
 reach a broader audience, and library consumers greater 
 flexibility.

 I'll post on the D "announce" thread when I have something 
 working, and I'd definitely appreciate tests/bug-reports at 
 that time!


 I was also thinking in the direction of enabling D to use 
 existing Julia code seamlessly, so you can just call it from 
 D (extern(J)), and maybe even efficiently compile it into 
 binaries along with D code, as you would with extern(C) calls 
 now.


 It's really easy to do that with R. There is a package RInside 
 that makes it trivial to embed R in a C++ program, and it's 
 not difficult to use with D.


 Would be cool if we had something like this for Julia (if it 
 really catches on).


I guess you can call D from Julia very easily via the C API and 
would just need to declare C calling convention in your D code.  
It may be that with a combination of Julia and D one has the best 
of both  worlds - no compromise with speed and efficient resource 
use on the number crunching with a nice shell / Ipython notebook 
that is still pretty fast on the front end.

Nicer would be a wrapper a la PyD that seamlessly translates 
between types.

Then the other thing is to translate julia.h into D so that you 
can embed Julia.  That's a little work but not so hard.  More 
about how this works with C here:

http://docs.julialang.org/en/release-0.3/manual/embedding/
Dec 11 2014
next sibling parent "bachmeier" <no spam.com> writes:
On Friday, 12 December 2014 at 06:57:24 UTC, Laeeth Isharc wrote:


 I guess you can call D from Julia very easily via the C API and 
 would just need to declare C calling convention in your D code.
  It may be that with a combination of Julia and D one has the 
 best of both  worlds - no compromise with speed and efficient 
 resource use on the number crunching with a nice shell / 
 Ipython notebook that is still pretty fast on the front end.

 Nicer would be a wrapper a la PyD that seamlessly translates 
 between types.

 Then the other thing is to translate julia.h into D so that you 
 can embed Julia.  That's a little work but not so hard.  More 
 about how this works with C here:

 http://docs.julialang.org/en/release-0.3/manual/embedding/


That's interesting. I hadn't seen it before.

I communicated with John Myles White via Twitter some months ago, 
and he said shared libraries for Julia should be coming. That 
would mean you could compile Julia functions and call them 
directly from D. This type of embedding is what you get with, 
say, Guile Scheme. The shared library approach would be a lot 
more convenient.
Dec 12 2014
prev sibling parent "jmh530" <john.michael.hall gmail.com> writes:
The downside about calling embedding Julia is C is that 
everything's a pointer to the heap and you have to manually call 
the garbage collector. If the same thing were implemented in D, 
then D can handle the garbage collection as per normal. It seems 
like D is a better fit for Julia than C in that regard.

On Friday, 12 December 2014 at 06:57:24 UTC, Laeeth Isharc wrote:

 On Wednesday, 7 May 2014 at 14:57:36 UTC, Chris wrote:

 On Wednesday, 7 May 2014 at 12:05:10 UTC, bachmeier wrote:

 On Wednesday, 7 May 2014 at 09:16:01 UTC, Chris wrote:

 On Tuesday, 6 May 2014 at 23:19:47 UTC, Mason McGill wrote:

 On Tuesday, 6 May 2014 at 11:28:21 UTC, Chris wrote:

 Maybe it's time to think about a D interface to Julia. If 
 Julia catches on within the scientific community, it would 
 be good to have a foot in the door. Science quickly 
 creates large code bases, unfortunately, so far it's 
 mostly Python and Matlab which makes it hard to use the 
 algorithms in real world applications.


 I've actually been working on just that, on and off for a 
 few months now. Such a thing is kind of "anti-Julian", 
 though, since one of Julia's main goals is to reduce or 
 eliminate the need for mixed-language projects.

 However, with D, you can compile small shared libraries 
 that can be automatically bound to your users' favorite 
 dynamic runtimes (via compile-time reflection). I'm hoping 
 this will be good for both D and Julia, allowing library 
 developers to reach a broader audience, and library 
 consumers greater flexibility.

 I'll post on the D "announce" thread when I have something 
 working, and I'd definitely appreciate tests/bug-reports at 
 that time!


 I was also thinking in the direction of enabling D to use 
 existing Julia code seamlessly, so you can just call it from 
 D (extern(J)), and maybe even efficiently compile it into 
 binaries along with D code, as you would with extern(C) 
 calls now.


 It's really easy to do that with R. There is a package 
 RInside that makes it trivial to embed R in a C++ program, 
 and it's not difficult to use with D.


 Would be cool if we had something like this for Julia (if it 
 really catches on).


 I guess you can call D from Julia very easily via the C API and 
 would just need to declare C calling convention in your D code.
  It may be that with a combination of Julia and D one has the 
 best of both  worlds - no compromise with speed and efficient 
 resource use on the number crunching with a nice shell / 
 Ipython notebook that is still pretty fast on the front end.

 Nicer would be a wrapper a la PyD that seamlessly translates 
 between types.

 Then the other thing is to translate julia.h into D so that you 
 can embed Julia.  That's a little work but not so hard.  More 
 about how this works with C here:

 http://docs.julialang.org/en/release-0.3/manual/embedding/
Jan 13 2015
prev sibling parent "Brian Rogoff" <brogoff gmail.com> writes:
On Tuesday, 6 May 2014 at 11:20:33 UTC, Paulo Pinto wrote:

 On Tuesday, 6 May 2014 at 09:11:30 UTC, Chris wrote:

 I recently came across this article 
 http://www.wired.com/2014/02/julia/. On the Julia homepage 
 there are some benchmarks times relative to C. I know that 
 bearophile has mentioned Julia several times on this forum. 
 Has anyone compared D's vs Julia's performance as well as 
 design features?


 I can only comment on design features.

 You can think of Julia as a dynamic language similar to Python, 
 with optional typing and for such a young language, a quite 
 good JIT compiler backed by the LLVM backend.

 It is a multi-paradigm language, with an OO approach based on 
 multi-methods and direct support for scientific programming.

 The target audience are the scientifc community that makes use 
 of R, Python with NumPy and so on, which are currently 
 disappointed with the performance of said systems. Their goal 
 is to keep the programming flexibility of R and Python, while 
 improving the performance without having to be forced to write 
 C code.


Excellent summary, one quibble, you omit MATLAB and Octave users 
from your target audience, when they may be the most important 
one. Julia reads much more like MATLAB than like R or Python, and 
numerical linear algebra is one of the things Julia is being 
aimed at.

It has a very rich language of types, and a macro system. 
Disappointingly, whilst you can annotate function arguments and 
variables with types, you can't annotate the function itself with 
a return type.

TL;DR MATLAB reimagined by Lisp hackers. I like it!

Not really competing in the same space as D. Yes, I know, I'm 
pigeonholing D, which is supposed to be a wide spectrum language, 
etc. etc.
May 06 2014