[swift-evolution] JIT compilation for server-side Swift
younes.m at gmail.com
Mon Jul 10 13:25:44 CDT 2017
On Mon, Jul 10, 2017 at 1:31 PM, Benjamin Spratling <bspratling at mac.com>
> I'm aware that Java re-compiles sections to make incremental performance
> improvements based on a statistical analysis of usage. I'm not familiar
> enough with other uses of JIT on the backend to know what advantages it
> would have, beyond less time from begin compile to launch. Could you list
> a few benefits?
The primary benefit is better performance by being able to exploit
knowledge about the program's behaviour and the hardware and software
environment it's running in that is only (or at least more easily and
accurately) available at runtime. In the case we're interested in "less
time from begin compile to launch" would not be a benefit, since we're
interested in JIT compiling an already built program.
> One of the goals of the Swift team appears to have been to achieve
> predictable performance, to the tune of finding object deallocations as too
> unpredictable. So would you envision this as being an opt-in per compile?
Variations in behaviour and performance are, unfortunately, a common hazard
with JIT compilation. It depends on the implementation of the JIT in
question of course; if you put emphasis on predictability you can certainly
engineer a JIT that favours predictability over peak performance. I
personally think anyone embarking on this sort of thing would hopefully
keep their users' concerns in mind and try not to subvert the language's
design goals and principles if it can be helped.
Opt-in/out is an interesting idea (that I've personally considered more so
for my own debugging purposes). An annotation that works like the familiar
inline/alwaysinline/neverinline might be a useful with the hope being that
a JIT would hopefully do "the right thing" and free you from having to care.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution