3 ms·

> the startup speed problem can be solved in Julia and they don't need a rockstar advisor to do it. I think the solutions are already pretty well known. > And

• dTal 6y ago
  Julia is a compiled language, like C. Using it in this way is basically like writing a shell script in C and calling GCC on every invocation. You can't expect good performance from that, and it's really a testament to Julia that it feels so dynamic that you feel as it it should do that. If you AOT-compiled your Julia "script" (program) to a binary and invoked that, your startup time problems would go away. Julia's "application deployment" stack is underdeveloped compared to its REPL experience, but it's still possible to do this today with PackageCompiler.jl and will only get easier with time. I think that will prove to be the "right" way to solve this problem in the long run. (Or, if you don't care about performance, you can just turn off the compiler and interpret everything, and you basically have Python-but-in-Julia. Fast startup, slow running. Just run it with julia --compile=no)
  • enriquto 6y ago
    > writing a shell script in C and calling GCC on every invocation. You can't expect good performance from that Of course you can. Have you ever used the "-run" option of the TCC compiler? It's blazingly fast. With gcc it's a bit slower, but still orders of magnitude faster than julia. You can use pre-compiled libraries and the linking to your freshly compiled code is extremely fast. The fact is that compiling and linking C code is much faster that just launching the Julia environment with some packages. There's no fundamental reason for that enormous disparity in running time. I agree that it is a completely irrelevant nuisance for most people; but still, for some workflows not blessed by the Julia developers, it is the main point of friction. EDIT: if you want to try it yourself, write the following text into a .c file, chmod +x it, and you can run it like a C script on most unix systems: //usr/bin/gcc -O0 "$0" -lpng && exec ./a.out "$@" #include <png.h> int main(int c, char *v[]) { // do stuff with png images return 0; }
    • dTal 6y ago
      Point taken, but I think you overreach a bit with: >There's no fundamental reason for that enormous disparity in running time I mean... Julia does full type inference, which it uses to present a dynamic type interface. It's not necessarily possible to statically compile a module ahead of time, because the module is designed to be generic and will generate different code if fed different types, which is how Julia attains its extraordinary composability. In other words, it's a much nicer language than C, and correspondingly much harder to compile. I'd call that a pretty fundamental reason. Perhaps C was a poor example for me to pick. C++, maybe? p.s. your "script" example clobbers any file named "a.out" in the current directory.
      • enriquto 6y ago
        > In other words, it's a much nicer language than C, and correspondingly much harder to compile. Sounds like an anti-feature to me. What I want is "matlab with fast loops". I couldn't care less about "extraordinary composability", "full type inference" or "genericity". Well, I do care because these unneeded features make my stuff much slower. It's a hefty price to pay for uncalled-for features! Yes, my script was just a silly joke, to show that compiling and linking C code is really fast.
        • dTal 6y ago
          Do you want a dynamic language with the speed of C? Then you want type inference.
          • enriquto 6y ago
            This is not necessary. There could be a single type, for example (e.g., the multidimensional array of floats).
            • shakow 6y ago
              And how do you multiple dispatch on that? But if you just want a free MATLAB, use Octave.
• deleted 6y ago
  [deleted]