You could use the method tracking approach to deal with staged functions, too.
Say you include running tests as a compilation step. You compile what you can, run the tests with jit enabled (which generates a bunch of specialised code, including for staged functions), then dump that code in a binary. That could greatly benefit the startup time of compiled code, since if you have good tests you'll barely need the JIT at runtime at all. Which then means you can remove the JIT without sacrificing performance. How does that sound? On 30 Dec 2014 20:10, "Jeff Bezanson" <[email protected]> wrote: > We can do what Mike described above with --compile=all. That will > generate at least working code for everything, with the notable > exception of staged functions. --compile=no will turn off the JIT. > However something we still need to do is separate libjulia and > libjulia-codegen, so there can be a version of the runtime that > doesn't include LLVM. > > I'm not sure what to do about staged functions. I suppose in > --compile=all mode, if a staged function throws an error then > compilation should also stop with an error, instead of moving the call > to runtime as usual. > > On Tue, Dec 30, 2014 at 1:23 PM, Tobias Knopp > <[email protected]> wrote: > > :-) Well what is called "julia runtime" does exactly that: generate code > on > > the fly ("just in time") > > > > Julia currently has no interpreter but Jameson has some experimental > code to > > use an LLVM interpreter > > > > Tobi > > > > Am Dienstag, 30. Dezember 2014 18:22:54 UTC+1 schrieb Spencer Russell: > >> > >> Bummer. Some quick googling seems to confirm that Apple still doesn't > >> allow JIT-compiled code. They do allow interpreted code, but only if the > >> code is shipped with the app and not loaded from elsewhere. > >> > >> Can you clarify "static binaries will rely on the Julia runtime / JIT, > at > >> least to begin with"? If I understand the Apple rules, basically it will > >> disallow jumping to any dynamically-generated code. So the Julia runtime > >> shouldn't pose a problem, as long as the executable code isn't > generated on > >> the fly. > >> > >> > >> peace, > >> s > >> > >> On Tue, Dec 30, 2014 at 12:09 PM, Mike Innes <[email protected]> > wrote: > >>> > >>> In principle, although last time I checked Apple doesn't allow apps to > >>> use JIT compilation, so we'd need fully static compilation first. I > don't > >>> know exactly what the precompilation roadmap looks like, but my > >>> understanding is that static binaries will rely on the Julia runtime / > JIT, > >>> at least to begin with. > >>> > >>> On 30 December 2014 at 16:55, Spencer Russell <[email protected]> > >>> wrote: > >>>> > >>>> Once it's running on ARM it should be possible to use the C API to > call > >>>> into Julia code from ObjC, right? I suppose that doesn't address the > OP > >>>> question about GUI dev in Julia, but at least using Julia for compute > within > >>>> a mobile app should be pretty feasible in the not-so-distant future. > >>>> > >>>> > >>>> peace, > >>>> s > >>>> > >>>> On Tue, Dec 30, 2014 at 9:50 AM, Mike Innes <[email protected]> > wrote: > >>>>> > >>>>> I hope we'll one day have ObjectiveC.jl running on iOS, but that day > is > >>>>> a long way off. > >>>>> > >>>>> On 30 December 2014 at 02:06, Stefan Karpinski <[email protected] > > > >>>>> wrote: > >>>>>> > >>>>>> You'd have to get Julia running on a mobile phone first, which we > may > >>>>>> be getting close to but as far as I know has not been accomplished > yet. > >>>>>> > >>>>>> On Mon, Dec 29, 2014 at 8:18 PM, <[email protected]> wrote: > >>>>>>> > >>>>>>> Are there any package in the works for an NUI or some mobile GUI > for > >>>>>>> Julia? > >>>>>> > >>>>>> > >>>>> > >>>> > >>> > >> > > >
