[llvm-dev] LLVM Orc Weekly #28 -- ORC Runtime Prototype update

[Lang Hames via llvm-dev]

Hi Kevin,


> Would this introduce start-up latency based on the size of the
> compilation? JIT jobs with 100-200MB of source are not uncommon here, and
> I’d hate to see latency get much worse.


Short answer: I don't see this adding measurable latency for your use case.

Longer answer:

I think the runtime will be non-mandatory: If you're not going to use any
of the features you could opt out of loading it, in which case there will
be no overhead at all.

If you load the runtime but don't use it you will pay a small cost each
time a lookup traverses the StaticLibraryDefinitionGenerator for the
runtime. The cost would be one virtual call, plus N * DenseMap<uintptr_t>
lookup. You can almost certainly arrange your libraries so that this cost
is never paid in practice (by making the runtime the last thing searched).

The first time each feature (laziness, thread locals, dlfcn call, etc.) is
used the JIT will load and link the corresponding part of the library. This
will involve jit-linking a few kilobytes of pre-compiled code  at most, and
happens only once per feature per session.

I don't think any of this will be measurable against the cost of compiling
any source files, let alone tens or hundreds of Mb worth.

Are you using the concurrent compilation feature on Orc? If you're seeing
high startup latency on multicore machines that may offer a way to reduce
it.

-- Lang.


On Thu, Jan 21, 2021 at 8:48 AM Kevin Neal via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Would this introduce start-up latency based on the size of the
> compilation? JIT jobs with 100-200MB of source are not uncommon here, and
> I’d hate to see latency get much worse.
>
>
>
> A small enough fixed latency would be ok.
>
> --
> Kevin P. Neal
> SAS/C and SAS/C++ Compiler
>
> Compute Services
>
> SAS Institute, Inc.
>
>
>
>
>
> *From:* llvm-dev <llvm-dev-bounces at lists.llvm.org> *On Behalf Of *Lang
> Hames via llvm-dev
> *Sent:* Tuesday, January 19, 2021 5:09 PM
> *To:* Stefan Gränitz <stefan.graenitz at gmail.com>
> *Cc:* Vivien Millet <vivien.millet at gmail.com>; Athul Acharya <
> aacharya at gmail.com>; LLVM Developers Mailing List <llvm-dev at lists.llvm.org>;
> kris <cq.personal at gmail.com>; Jared Wyles <jared.wyles at gmail.com>;
> Frances Mocnik <fmocnik at gmail.com>; Jacob Lifshay <
> programmerjake at gmail.com>; Christian Schafmeister <meister at temple.edu>
> *Subject:* Re: [llvm-dev] LLVM Orc Weekly #28 -- ORC Runtime Prototype
> update
>
>
>
> *EXTERNAL*
>
> Big question for JIT clients: Does anyone have any objection to APIs in
> ORC *relying* on the runtime being loaded in the target? If so, now is the
> time to let me know. :)
>
>
>
> I think possible objections are JIT'd program startup time (unlikely to be
> very high, and likely fixable via careful runtime design and pre-linking of
> parts of the runtime), and difficulties building compiler-rt (which sounds
> like something we should fix in compiler-rt).
>
>
>
> If we can assume that the runtime is loadable then we can significantly
> simplify the TargetProcess library, and TargetProcessControl API, and
> further accelerate feature development in LLVM 13.
>
>
>
> -- Lang.
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210121/35577bf8/attachment.html>