3 ms·

Where is this "use" part of which you speak? Aggressive JIT languages are historically slow at startup. The typical tradeoff (similar to the server/client Jav

by reeses 13y ago

Where is this "use" part of which you speak? Aggressive JIT languages are historically slow at startup. The typical tradeoff (similar to the server/client Java VM flags) is to amortize the optimizations over the length of the application if startup time is a factor. If you start Julia (or Mathematica, Excel, or whatever) up every time you need to 'graphically explore data', you're doing it wrong. Unless you fubar your environment (not that I ever do this on a regular basis), there isn't a great reason to restart your exploratory environment.

rdtsc 13y ago
> Where is this "use" part of which you speak Maybe you don't want to use the old repl, there there is something else going on there and you don't want to mess it up. Maybe I want to show someone an example, or try something out quickly. I use and spawn ipython windows all the time. Sometimes I have 4 open at the same time. > Aggressive JIT languages are historically slow at startup. Explaining the reason for the slow start-up doesn't make the slow startups faster.
- deleted 13y ago
  [deleted]
- coldtea 13y ago
  >> Aggressive JIT languages are historically slow at startup. Explaining the reason for the slow start-up doesn't make the slow startups faster. No, but insisting that you want startups faster, when you've been explained the technical reasons why they are slow, doesn't make them faster either. To me it sounds like: "This ball shouldn't fall to earth". "It fell because of gravity". "Explaining the reason it fell, doesn't make it go upwards".
  - rdtsc 13y ago
    > No, but insisting that you want startups faster, when you've been explained the technical reasons why they are slow, doesn't make them faster either. Oh please. "We've explained the technical reasons to you" excuse. As a customer the response to that is "ok, good luck with that, I am not using your product". > "This ball shouldn't fall to earth" / "It fell because of gravity" / "Explaining the reason it fell, doesn't make it go upwards". No the answer to that is, screw this planet, I'll go fly into space and find another planet. Which is the response people have with software they don't like. It is more like: "Oh your database is slow" and getting the response of "Well of course it is,the locks at level 3 in our API have not been optimized because John is on vacation still. Geez how dare you not accept that as a valid answer?" See you've equated software features hard laws of physics. So escaping from it is "ridiculous". To be more serious, having an interpreter JIT a module only if you use, on-demand, or save the trace of it, across execution maybe he hard but doesn't require changing the fine structure constant.
    - reeses 13y ago
      In fact, this is how a lot of heavy iron operates. You can use the same "binaries" ('TIMI') on your i/System i/AS400/POWER7 and the system will recompile what is essentially bytecode and save the machine-specific object code. Alpha did something similar, and a number of feedback-directed/profile-based optimizing compilers will perform similar optimizations, but they are less flexible unless repeated cycles are performed in the deployed environment.
rossjudson 13y ago
Pure JIT compilation is historically slow at startup. There are hybrid approaches, such as caching code once it's been compiled, and just loading the cached version on the next startup. IBM Java 7 does this (not just for shared classes, which client-side Java has done for a long time, but for an application's classes, running on a server vm), and it cuts about 70% of the startup time out of my app.

by reeses 13y ago

rdtsc 13y ago

> Where is this "use" part of which you speak Maybe you don't want to use the old repl, there there is something else going on there and you don't want to mess it up. Maybe I want to show someone an example, or try something out quickly. I use and spawn ipython windows all the time. Sometimes I have 4 open at the same time. > Aggressive JIT languages are historically slow at startup. Explaining the reason for the slow start-up doesn't make the slow startups faster.

deleted 13y ago
[deleted]
coldtea 13y ago
>> Aggressive JIT languages are historically slow at startup. Explaining the reason for the slow start-up doesn't make the slow startups faster. No, but insisting that you want startups faster, when you've been explained the technical reasons why they are slow, doesn't make them faster either. To me it sounds like: "This ball shouldn't fall to earth". "It fell because of gravity". "Explaining the reason it fell, doesn't make it go upwards".
- rdtsc 13y ago
  > No, but insisting that you want startups faster, when you've been explained the technical reasons why they are slow, doesn't make them faster either. Oh please. "We've explained the technical reasons to you" excuse. As a customer the response to that is "ok, good luck with that, I am not using your product". > "This ball shouldn't fall to earth" / "It fell because of gravity" / "Explaining the reason it fell, doesn't make it go upwards". No the answer to that is, screw this planet, I'll go fly into space and find another planet. Which is the response people have with software they don't like. It is more like: "Oh your database is slow" and getting the response of "Well of course it is,the locks at level 3 in our API have not been optimized because John is on vacation still. Geez how dare you not accept that as a valid answer?" See you've equated software features hard laws of physics. So escaping from it is "ridiculous". To be more serious, having an interpreter JIT a module only if you use, on-demand, or save the trace of it, across execution maybe he hard but doesn't require changing the fine structure constant.
  - reeses 13y ago
    In fact, this is how a lot of heavy iron operates. You can use the same "binaries" ('TIMI') on your i/System i/AS400/POWER7 and the system will recompile what is essentially bytecode and save the machine-specific object code. Alpha did something similar, and a number of feedback-directed/profile-based optimizing compilers will perform similar optimizations, but they are less flexible unless repeated cycles are performed in the deployed environment.

rossjudson 13y ago

Pure JIT compilation is historically slow at startup. There are hybrid approaches, such as caching code once it's been compiled, and just loading the cached version on the next startup. IBM Java 7 does this (not just for shared classes, which client-side Java has done for a long time, but for an application's classes, running on a server vm), and it cuts about 70% of the startup time out of my app.