►
From YouTube: RustConf 2019 - Rust for Weld, a High Performance Parallell JIT Compiler by Shoumik Palkar
Description
RustConf 2019 - Rust for Weld, a High Performance Parallell JIT Compiler by Shoumik Palkar
Weld is an open source Rust project that accelerates data-intensive libraries and frameworks by as much as 100x. It does so by JIT-compiling a custom parallel intermediate representation and optimizing across functions within a single library as well as across different libraries, so developers can write modular code and still get close to bare metal performance without incurring expensive data movement costs. We first describe our use of Rust to build an extensible, performance sensitive compiler for Weld. In particular, we discuss challenges in writing a native code generator with LLVM in Rust, challenges in reducing JIT compilation times within our compiler, and architecting the compiler for both extensibility using Rust's powerful trait system, but also portability of our library across other languages, such as Python and C. Finally, we discuss our experiences with building a parallel runtime in Rust, and the unique challenges associated with calling unsafe Rust from JIT'd code.
A
I'll
first
talk
a
little
bit
about
what
weld
is
and
what
its
motivations
are
followed
by
the
path
that
we
kind
of
took
that
you
know,
landed
us
at
rust
and
then
finally,
I'll
talk
about
some
of
the
features
of
rust
that
we
use
in
weld
and
also
where
we
hope
to
take
the
project
from
here.
So
jumping
right
in
the
motivation
for
the
weld
project
is
that
modern
data
analytics
applications
combine
many
disjoint
processing,
libraries
and
functions
so
taking
the
Panda
or
say
the
Python
ecosystem.
As
an
example.
A
A
typical
Python
data
science
application-
may
you
know,
load
some
data
and
pandas
and
do
some
pre-processing,
maybe
train
a
machine
learning
model
and
scikit-learn
and
then
maybe
do
some
statistical
analysis
in
numpy.
So
this
is
good
because
on
one
hand,
you
get
great
results,
kind
of
leveraging
the
work
of
thousands
of
authors
who
are
implementing
the
best
algorithms
in
each
domain.
But
on
the
other
hand,
in
these
kinds
of
libraries,
you
generally
don't
get
any
optimization
across
individually,
written
and
optimized
functions.
A
So
how
bad
is
this
problem
that
we
don't
get
any
cross
function
optimization?
It
turns
out
that
the
growing
gap
between
memory
speeds
on
newer
hardware
and
processing
speed
on
new
hardware.
It's
kind
of
being
this
rigid
function
call
interface
to
these
kinds
of
libraries
worse
and
worse
over
time,
so
as
an
example
of
there.
A
The
interface
to
these
libraries
is,
you
have
some
functions
and
you
throw
some
data
at
them
and
they,
you
know,
crunch
some
numbers
and
give
you
back
a
result,
and
because
of
this,
when
you
actually
look
at
the
execution
of
these,
like
typical
data
science
type
workflows,
it
looks
something
like
this.
You
have
some
memory
sitting
around
and
you
call
a
function
and
basically,
what
that
entails
is
that
you
give
it
some
data,
it
processes
something,
and
then
it
gives
you
back
a
result.
A
All
these
kind
of
data
analytics
libraries
that
you
hear
about
compared
to
an
optimized
just
c
or
washed
implementation.
So
if
I
were
to
take
the
same
application
and
write
it
and
see,
there
would
be
this
huge
kind
of
gap
between
what
people
actually
use
to
this
kind
of
stuff
today
and
what
the
hardware
is
actually
capable
of
so
well.
This
is
a
common
runtime
for
data
analytics
libraries.
That
kind
of
attempts
to
tackle
this
problem
and
the
approach
that
well
takes
is
something
like
this.
A
There's
these
libraries
for
different
domains,
just
sequel
or
machine
learning,
and
they
effectively
target
a
common
parallel
runtime
and
instead
of
executing
each
function
individually,
this
runtime
will
act
like
a
you
know
like
a
standard,
compiler
it'll,
look
at
all
your
code,
just
at
runtime,
instead
of
at
compile
time
and
it'll
basically
run
an
optimizer
over
it
and
JIT
code
to
execute
during
the
execution
of
your
application,
and
you
can
get
code
for
these
different
kind
of
parallel
platforms
such
as
CPUs
or
GPUs,
or
something
else
so
internally.
Well,
it
has
a
bunch
of
components.
A
A
So
if
we
look
at
kind
of
the
thousand
foot
view
of
how
a
program
using
world
executes
it
starts
with
some
user
application,
that's
unmodified.
So
the
idea
here
is
that
for
users,
Weld
is
kind
of
invisible,
but
for
library
developers
you're,
you
know
replacing
the
implementation
of
your
library
functions
to
integrate
with.
Well.
So
let's
say
we
have
a
function
with
some
Weld
enabled
when
a
user
calls
a
function
instead
of
evaluating
those
functions
internally.
A
So
when
you
started
with
Weld,
it
was
kind
of
meant
to
target
these
cross
library,
optimization
based
workloads,
but
over
time
we've
kind
of
been
we've
kind
of
seen
that
it's
been
useful
for
other
things
as
well.
So
as
a
few
examples,
we've
seen
people
use
well
to
build
jits
or
new
physical
execution
engines
for
databases
or
analytics
frameworks.
We've
seen
it
being
used
just
within
individual
libraries.
So
if
you
just
want
better
kind
of
native
code
execution
and
a
Python
library
using
a
JIT,
compiler
is
a
great
way
to
do
that.
A
So
we've
seen
it
being
used
for
that,
and
we've
also
been
seen
it
being
used
to
target
new
kinds
of
parallel
hardware
and
the
reason
that
weld
is
especially
nice,
for
that
is
because
the
ir
is
just
structured
in
a
way
that
it
can
assume
that
a
bunch
of
things
are
inherently
parallel.
So
if
you
have
hardware
such
as
GPUs
or
vector
accelerators,
the
IR
is
kind
of
an
attractive
way
to
kind
of
bridge
high-level
code
with
the
kind
of
machine
specific
code,
so
just
quickly
to
provide
some
context
and
the
kinds
of
speed
ups.
A
A
So
this
is
a
because
we
parallelized
the
single-threaded
libraries
numpy
and
pandas,
but
it's
also
because
we
can
do
optimizations
such
as
loop
fusion,
that
you
know
like
iterators
and
rush
can
do,
for
example,
but
it's
doing
them
over
these
kind
of
native
libraries
and
I
want
to
point
out
that
pan
doesn't
numpy
are
written
and
see
internally.
So
this
isn't
like
comparing
against
like
some
weird
Python
loop
or
something
as
another
example.
A
We
were
able
to
optimize
this
image,
whitening
plus
linear
regression,
workflow
in
tensorflow
and
numpy,
and
this
is
comparing
against
tensor
flows,
own
kind
of
excel
a
compiler,
so
cancer
for
all
journey.
Has
this
compiler
that
it
uses
to
do
things
like
operator
fusion,
but
because
we
can
actually
look
across
library
boundaries.
We
get.
We
still
get
a
pretty
nice
speed
up
here
and
finally,
we
can
also
use
well
to
kind
of
just
optimize
the
execution
of
things
like
data
analytics
frameworks.
A
So
basically
you
can
just
type
in
weld
programs
here.
So
here's
a
simple
one
that
just
adds
one
two
input
and
you
can
see
that
it
basically
just
dumps
out
some
information
on
things
that
it's
doing
so
here
it
did.
Some
macro
substitution,
followed
by
type
inference.
So
this
isn't
gonna
look
super
interesting
because
this
program
is
pretty
simple:
you
can
hit
enter
and
kind
of
walk
through
the
different
passes
that
the
compiler
applies.
Here.
A
It's
not
really
going
to
do
much
because
it's
kind
of
hard
to
optimize,
adding
one
to
a
number,
but
you
can
also
get
some
stats
about
how
the
compiler
does
there.
So,
if
you
look
at
the
right
side
here
now,
there's
a
slightly
more
complicated
program
where
we're
computing.
The
sum
of
squares,
so
that
first
line
with
the
map
is
basically
squaring
each
integer
that
we
pass
in,
and
the
second
line
is
summing,
the
squared
integers,
and
you
might
be
wondering
why
we've
actually
written
this
program
in
this
way
right.
A
So
this
is
kind
of
how
you
can
expect
a
typical
world
program
to
look
so,
for
example,
a
numpy
program
that
call
or
sorry
an
umpire
function
that
squares
things
might
generate
the
first
line
of
this
program
and
a
numpy
function
that
you
know
computes
as
some
might
generate
the
second
line,
and
it's
up
to
well
to
kind
of
look
at
these
individual
fragments
and
come
up
with
something
more
reasonable.
So
we'll
go
ahead
and
load
this
into
the
repple.
So
I'll
just
hit
load
demo,
dot
weld
here
and
right
off
the
bat.
A
You
can
see
that
this
program
looks
fairly
different
from
what
we
have
on
the
right
side.
So
here
we've
done
macro,
substitution
and
type
inference,
and
the
reason
this
program
looks
so
different
is
because
map
and
summon
well
they're,
actually
macros,
that
expand
into
these
parallel
for
loop
operators
on.
A
So
you
can
see
there's
that
for
operator
there,
and
that
just
means
that
we're
iterating
over
the
input
that
we
give
it
in
parallel,
so
that
first
for
loop
is
iterating
over
a
in
parallel,
and
it's
using
this
thing
called
an
appender
to
basically
append
items
to
a
list.
So
that's
our
kind
of
map
that
constructs
the
squares
and
the
second
floor.
Loop
is
actually
doing
the
sum,
so
that
merger
with
the
plus
in
it
that's
just
a
way
to
represent
a
parallel
aggregation
in
well.
A
So
these
are
just
details
about
the
ir
that
I'm
not
gonna
spend
too
much
time
on,
but
that's
that's
basically
how
the
program
looks
like,
and
it's
kind
of
unfurnished
for
so
well
now,
step
through
the
optimizer
and
look
at
what
it
does
so
this
in
line.
Let
pass
as
an
example
got
rid
of
the
assignments
and
kind
of
inline
those
loops,
but
we
still
have
those
two
passes
over
the
data
stepping
through
it
a
couple
more
times.
A
You
can
see
this
loop
fusion
pass,
which
is
probably
the
most
interesting
one
in
this
example,
actually
got
rid
of
one
of
the
loops
and
it
inlined
the
squaring
of
the
input
into
that
aggregation.
So
now
we're
just
doing
one
pass
over
the
data
so
we'll
step
through
it
a
little
bit
more
and
you
can
see
that
it
also
vectorized
this
thing
by
basically
introducing
these
sim
da
tur
things
that
allow
the
backend
to
generate
sim
decode.
And
finally,
we
get
some
statistics
about
how
the
compiler
did.
A
A
The
first
kind
of
Weld
compiler
implementation
was
in
scala,
so
I'll
briefly
talk
about
what
was
good
about
Scala
and
then
I'll
talk
about
what
was
bad
and
why
we
ended
up
with
rust.
So
the
good
things
about
Scala.
The
main
reason
that
we
chose
Scala
to
begin
with,
was
because
it
had
these
algebraic
types,
and
this
really
nice
pattern
matching
mechanism.
So
all
those
rules
that
I
showed
you
in
the
demo.
A
So
with
Scala
you
can
use
all
the
things
that
Java
has,
and
it
also
also
had
things
like
collections
and
everything,
so
that
just
makes
you
know,
building
stuff
easier
and
also
my
adviser
liked
it.
So
that
obviously
impacted
things
as
well.
So
going
back
to
this
pattern
matching
example:
here's
an
example
of
converting
a
boolean
expression
into
a
short-circuited
version
of
that
boolean
expression.
So
as
an
example,
this
end
expression
it
computes
the
computes
left
and
then
computes
right
and
then
it
takes
the
N
and
then
returns
either
true
and
false.
A
So
if
we
want
to
convert
this
to
a
short-circuited
expression,
we
can
convert
it
to
an
if
statement
where
it
evaluates
left.
If
left
is
true,
we
evaluate
right
and
if
left
is
false,
you
just
return
false
okay,
and
you
can
see
that
writing
these
kinds
of
pattern,
matching
rules
for
an
optimizer,
or
you
know
these
kind
of
correctness,
rules
as
well.
A
Okay,
this
is
a
talk
about
rust,
and
so
naturally
there
are
some
bad
things
that
we
ran
into
that
led
us
to
move
on
and
kind
of.
The
main
bad
thing
about
Scala
was
that
it
was
very
hard
to
embed
into
other
things,
and
you
know
hindsight
is
20/20,
but
we
should
have
known
this,
but
it's
not
great.
If
you
have
some
Python
program
running
and
you
want
to
compile
something
and
you
have
to
fire
up,
like
a
you
know,
100
megabyte
JVM
process
to
do
that.
A
So
that
was
probably
the
biggest
reason
why
we
decided
to
move
away
from
this
kind
of
managed
runtime
world
auxilary
reasons.
Jit
compilation
times
we
also
found
were
pretty
slow
for
larger
programs
for
smaller
programs
that
didn't
really
matter-
and
this
was
again
just
due
to
the
fact
that
we
were
actually
interpreting
code
and
usually
we
weren't
running
things
enough
for
the
JVM
to
you
know,
compile
things
to
native
code.
A
A
Finally,
the
runtime
also
had
to
be
in
a
different
language
right,
so
we're
ginning
code
and
this
jittered
code
is
just
some
arbitrary
machine
code.
That's
expected
to
be
scheduled
by
you
know
some
kind
of
threading
library,
and
you
know
there
was
no
way
that
we
were
going
to
use
like
Java
threads
for
that,
because
that's
that's
just
not
funny
so
effectively.
We
wanted
to
redesign
the
JIT
compiler,
the
core
API
and
runtime
from
the
gap
from
the
ground
up
because
of
these
kind
of
shortcomings,
of
the
language
that
we
were
using.
A
But
if
you
think
about
it,
these
three
things
have
some
fairly
different
requirements.
The
JIT
compiler
needs
things
like
pattern
matching
and
algebraic
data
type.
So
it's
nice
to
express
these
kind
of
optimization
rules.
The
core
API,
because
we
want
to
integrate
it
into
other
things-
needs
a
nicely
compatible
FFI
and
we
also
need
strong
support
for
parallelism
and
also
the
ability
to
control
kind
of
low-level
things
like
memory
layout.
Okay,
so
I
think
everyone
knows
where
I'm
going
with
this.
A
So
this
was
kind
of
what
led
us
to
rust,
just
kind
of
really
quickly
reiterating
the
requirements
we
had.
These
are
in
no
specific
order.
We
needed
speed
because
compilation
happens
at
runtime,
so
this
isn't
some
offline
compiler
right.
The
compilation
time
actually
counts
toward
what
the
user
sees.
We
needed
safety
because
we
were
embedding
things
into
other
libraries.
We
needed
a
managed.
We
did
not
want
to
manage
run
time
again
because
we
were
embedding
this
into
other
runtimes.
A
So
we
started
our
search
for
a
new
language
and
these
are
kind
of
the
languages
that
we
considered
up
off
the
bat
but
going
through
our
requirements.
It
was
pretty
easy
to
kind
of
knock
these
off
right,
so
we
wanted
things
to
be
fast
to
back
out
of
Python.
We
wanted
it
to
be
safe,
so
we
said
goodbye
to
c-plus.
A
We
didn't
want
to
manage
run
time,
so
there
went
oops.
There
went
going
and
Java
and
we
were
basically
left
with
Swift
and
rust
and
recall
that
this
is
back
in
like
2016
or
something
so
it
was
a
slightly
different
landscape
back
then
we
wanted
a
rich
standard
library.
We
wanted
these
functional
paradigms
for
things
like
pattern
matching,
so
both
of
them
kind
of
had
that
back
then,
and
we
also
wanted
a
good
package
manager
and
this
isn't
on
the
slides.
A
But
after
we
started
using
both
of
these
in
evaluating
them,
we
realized
that
we
also
wanted
a
good
community
and
that's
kind
of
a
rust
really
want
out
the
ability
to
have
crates
do
and
these
super
high
quality
packages,
and
also
you
know
the
rest
forums
and
everything
to
have
people
help
us
with
stuff
and
also
the
ability
to
ask
questions
that
weren't
related
to
iOS
development.
All
that
stuff
was
pretty
nice
and
it's
kind
of
what
sold
rust
for
us
at
the
end.
A
Okay,
so
I'll
dive
a
little
bit
into
how
we
actually
use
rust
for
building
weld
them.
So
the
first
iteration
of
using
of
weld
and
rust
was
basically
just
looking
at
the
compiler.
So
we
took
all
the
Scala
bits
of
our
code
and
we
ported
them
over
to
rust.
So
this
involves
the
core
API,
the
optimizer
and
also
the
compiler
backends.
A
Okay,
so
going
into
a
little
bit
more
detail
now
the
world
IR
itself
is
implemented.
Basically
as
a
tree
with
all
the
operators
represented
using
an
enum.
So
the
main
kind
of
construct
in
the
IR
is
this
thing
called
an
expression
or
expert
that
has
a
kind,
that's
the
kind
of
expression
it
is,
and
a
type
such
as
you
know,
integer
float
or
whatever
and
expert
kind
itself
is
basically
this
giant
enum
that
defines
all
the
different
kinds
of
operators
that
we
support.
So
you
might
wonder
why
we
actually
did
did
it
this
way.
A
Another
you
know
kind
of
strong
man
way
of
doing
it
is
to
use
something
like
trade
objects,
which
was
arguably
more
extensible.
So
if
you
want
to
add
more
things,
you
don't
have
to
go
and
update
this
enum
everywhere,
and
this
kind
of
goes
back
to
the
pattern
matching
thing
I
was
talking
about
a
while
back
these
genomes
make
pattern
matching
super
easy
and
basically
because
so
much
of
the
compiler
has
to
do
with
the
optimizer
rules.
This
was
kind
of
a
first
class
concern
for
us,
so
diving
into
that
a
little
bit
more.
A
We
were
pleasantly
surprised
that
the
pattern
matching
rules
were
fairly
similar
to
Scala,
despite
having
to
you
know,
get
around
the
borrowed
checker
and
everything.
So
in
most
cases
this
is
the
same
rule
that
we
had
from
before.
It's
basically
converting
binary
operations
into
short-circuited
operations,
all
you
have
to
do
is
match
on
target
pattern,
create
a
substitution
and
then
replace
the
expression
in
place.
A
So
there
was
one
kind
of
quirky
thing
that
we
had
to
deal
with
in
the
beginning.
While
we
were
learning
rust
and
that
was
learning
to
live
without
clones-
and
we
found
that
this
was
especially
difficult
with
these
kind
of
tree
and
graph
data
structures,
just
because
it's
an
easy
escape
hatch.
So
our
old
code
for
this
transform
looks
something
like
this
and
if
you
squint
at
this
code,
you
can
see
that
what
it's
basically
doing
is
that
it's
taking
your
entire
sub
program
and
copying
it
every
time.
A
A
So
we
knew
in
the
back
of
our
minds
that
there
were
some
combination
of
ref
and
ref
mud
and
an
mut
and
whatever
to
you
know,
fix
this,
but
it
was
easier
just
to
drop
in
some
clones
and
some
well-chosen
spaces
and
get
the
bar
checker
to
shut
up
for
a
couple
weeks.
But
unfortunately,
the
other
bad
thing
is
that
this
is
especially
fatal
for
performance
because
we're
fundamentally
dealing
with
recursive
data
structures
here.
So
this
ends
up
becoming
a
recursive
clone.
So
at
some
point
we
did
have
to
fix
these
issues.
A
So
our
solution
to
this
was
fairly
simple.
We
have
this
cake
call
now
and
basically
all
it
does.
Is
you
create
a
placeholder
expression,
and
then
you
use
this
mem
swap
to
you
know,
swap
it
out
and
he
returned
the
old
thing,
so
you
can
basically
drop
in
take
in
most
places
where
use
clone
and
as
long
as
you're
replacing
that
old
expression
that
you're
substituting.
A
This
is
basically
like
a
pointer
slop,
and
this
obviously
gives
us
some
pretty
substantial
and
performance
benefits.
It
was
just
you
know,
as
newcomers
to
the
language.
It
was
hard
for
us
to
kind
of
find
these
kinds
of
things.
I.
Think
Steven
is
key.
Note
even
said
that
mem
swap
used
to
be
part
of
the
syntax.
You
know
few
years
ago
and
I
can
totally
see.
Why
that's
the
case
right.
A
It
took
us
like
probably
a
year
to
find
that
this
mem
swap
utility
even
existed,
and
it's
our
fault
for
not
asking,
but
now
that
we
have
it,
you
know.
Performance
is
great
and
our
rules
are
also
be
easy
to
write.
So
we're
pretty
happy
other
things.
We
use
LLVM,
C
API
for
code
generation
and
it's
pleasantly
easy
to
interface
with
C
libraries
and
again.
This
is
in
large
part
thanks
to
cargo.
A
So
here's
some
code
that
you
don't
have
to
read,
but
it's
basically
taking
a
struct
and
generating
code
for
creating
that
struct
and
embedded
in
there
are
two
kind
of
llbmc
API
calls,
and
it
was
very
natural
just
to
you
know,
call
C
from
rust
and
also
the
other
way
around
which
I'll
talk
about
and
that
kind
of
made
it
easy
to
kind
of
take
the
huge
like
ecosystem
of
C
libraries
that
are
out
there
and
use
them
in
cases
where
you
know
the
same
thing
in
rust.
Didn't
exist.
A
Ff
eyes
are
also
very
easy
to
build
compared
to
Scala,
where
we
needed
things
like
these
weird
wrapper
objects.
We
needed
to,
you
know,
tell
the
GC
not
to
throw
our
stuff
away
and
so
forth.
In
rust.
We
basically
define
some
type.
You
can,
you
know
easily
specify
how
long
you
want
that
type
to
be.
You
know
we
made
an
alias
for
it,
and
then
you
basically
create
a
function
that
you
know
allocates
the
memory
on
the
heap
and
forgets
about
it.
A
A
So
it's
a
very
thin
layer
of
kind
of
connecting
the
C
world
we're
giving
an
interface
to
C
developers
that
they're
comfortable
with
and
also
kind
of
the
rust
world
where
everything
above
this
is
just
pure
rust-
and
you
don't
have
to
worry
about
this
stuff
anymore
and
I
also
want
to
say
that
you
can
almost
certainly
automate
this
kind
of
stuff
with
procedural
macros,
though
we
haven't
tried.
So
if
anyone
knows
of
any
crates
that
does
stuff
like
this,
please
let
me
know.
A
Okay.
Finally,
we
use
cargo
to
manage
literally
everything
about
our
project,
so
the
FFI
that
was
generated
on
the
previous
slide-
that's
a
header
for
that
is
generated
using
a
build
dot,
RS
file.
We
use
the
workspaces
to
build
tools
automatically.
So
you
know,
literally,
all
you
have
to
do
to
get
the
tooling
and
the
compiler
and
the
runtime.
Is
you
get
clone
and
carve
abode
police
and
everything
is
just
there
sitting
waiting
to
be
run.
So
that's
really
nice
Docs
and
testing
all
that
standard
stuff.
A
We
also
use
cargo
for
yeah,
I
love,
cargo,
I
think
it's
probably
one
of
the
most
underrated
features
of
rust,
just
because
it's
so
easy
to
use
and
get
started
with.
So
you
know,
people
often
say
that
rust
is
one
of
the
Hardware
programming
languages
to
learn
today.
I've
been
writing
C
for
10-15
years
now,
and
I
still
don't
know
how
to
write
a
proper
make
file
so
yeah,
if
you,
if
you
think
that
learning
rust
is
difficult,
yeah
try
to
write
a
make
file
or
auto
comm
for
C
make
or
whatever
those
other
things.
A
So
overall
life
was
pretty
good,
but
we
still
had
that
pesky
C++
runtime
and
that
led
to
the
usual
host
of
issues.
So
we
had
concurrency
bugs
that
were
unrelated
to
the
generated
code.
We
had
two
code
bases
which
wasn't
fun.
We
had
a
more
complex
build
system,
so
we
still
had
you
know
some
nested
makes
left
in
there
somewhere
we
had
to
logging
and
debugging
systems.
So
just
like
small
usability
things
like
that,
so
our
second
cut
of
valve
in
rust,
actually
ported
the
entire
runtime
to
use
rust.
A
As
well
so
the
fundamental
kind
of
architecture
picture
looks
the
same.
It's
just
that.
We've
replaced
the
chunk
that
was
in
C++
and
we've
kind
of
moved
it
into
question,
and
this
gave
us
some
advantages.
It's
safer
than
C
there's
really
no
guarantees
when
you're
interacting
with
this
arbitrary
code.
A
But
it's
definitely
things
like
scheduling
and
task
management
are
definitely
safer
than
they
were
before.
We
also
have
a
nice
single
logging
and
debugging
API,
so
you
can
set
a
log
level
in
the
rust
compiler
and
then
you'll
get
the
kind
of
same
logging
output
for
when
you're
running
generated
code,
which
is
nice,
and
it's
also
easier
to
pass
data
from
the
runtime
to
the
compiler
also.
A
So
this
was
easy
enough
before,
but
this
lets
us
do
things
like
asserting
the
size
of
some
generated,
structure
or
compiler
matches
the
size
that
we
expect
in
like
a
unit
test
or
something
it's
like
kind
of
clean
key
stuff
like
that.
That
just
ensures
that
stuff
is
clicking.
So
a
little
bit
of
detail
on
this.
A
So
the
way
that
this
runtime
works
is
as
follows.
So
you
basically
judge
some
machine
code
and
then
you
basically
call
into
rust
using
these
FFI
style
functions.
So
on
the
rest
side,
you
basically
have
this
type
definition
and
that's
all
there's
this
JIT
func
type
definition-
and
this
indicates
this
basically
refers
to
a
function
pointer
that
is
generated
somewhere
by
the
actual
JIT
compiler.
So
there's
some
function
somewhere
that
was
generated
because
you
took
some
Weld
ir
and
you
compiled
it
into
the
memory
of
the
existing
process.
A
And
then
you
have
this
run
task
function,
which
is
a
standard
everyday
rust
function,
except
it
has
this
c
wrapper
as
well
and
by
wrapping
it
as
like
a
FFI
function,
you
can
basically
call
that
function
from
the
generated
code.
So
this
is
what
that
looks
like
this
is
kind
of
scary-looking.
But
it's
not
that
bad.
You
basically
have
this
function,
f1
that's
generated
via
the
JIT,
and
then
you
have
some
code
that
does
some
one
packing
and
stuff,
and
then
you
have
the
run
task
function.
A
So
rhyme
task
basically
takes
f1,
which
is
a
function
that
we
generated
as
a
input.
So
this
is
just
a
pointer
and
run
task.
Is
just
written
in
rust
and
how
we
can
do
our
standard
rust
stuff
here,
so
we
can
use
the
standard
brush
library
to
spawn
threads.
We
can
you
know
time
tasks
do
load,
balancing
use
stuff
from
crazy.I
or
whatever.
A
The
only
funky
thing
is
that
we
have
this
call
to
f1
at
some
point
which,
from
rest
perspective,
is
just
this
kind
of
black
box
function
that
it's
calling
and
it
really
just
ends
up
calling
into
some
code
that
we
generated.
So
this
obviously
needs
to
be
wrapped
in
unsafe,
but
you
know
every
it's
it's
pretty
nice
just
because
you
get
there
kind
of
unify
the
compilation,
part
and
the
runtime
part
of
this
stuff.
A
Okay.
So
if
you're
interested
in
this
stuff,
we'd
love
contributors-
we
have
you
know
around
30
contributors
today
over
a
thousand
github
stars,
so
the
project
is
definitely
still
growing.
There's
many
many
things
to
do,
ranging
from
compiler
optimizations
to
fleshing
out
things
like
GPU
support,
and
we
also
have
contributions
by
many
other
groups
and
academia
and
Industry.
So
I
think
we
can
find
something
to
do.
No
matter
where
you
are
I
also
just
want
to
give
a
quick
shout
out
to
other
people
at
Stanford
who
contribute
to
this
project.
A
Obviously,
none
of
this
would
exist
without
them
and
now,
just
to
conclude,
rust,
we
thought
was
a
fantastic
fit
for
building
kind
of
a
modern,
high-performance,
JIT,
compiler
and
runtime.
Has
these
nice
functional
semantics
for
building
a
compiler?
It
also
has
the
native
execution
speed,
which
is
important
for
the
runtime,
but
also
for
the
JIT
compilation
part,
and
it
also
gives
you
the
kind
of
low-level
control.