SETH LADD: OK, we are live.
Here we are, special episode
of "Dartisans," with Dart
engineer Nicolas Geoffray.
Hello, Nicolas.
NICOLAS GEOFFRAY: Hello.
SETH LADD: Now where
are you today?
NICOLAS GEOFFRAY: I'm hanging
out in Zurich.
SETH LADD: This is awesome.
So you look like you're
in a little car.
Where are you?
NICOLAS GEOFFRAY: I could make
you a little tour, actually.
I don't know how it's
called in English,
but it's like a skillet.
SETH LADD: I think it's
a little gondola.
NICOLAS GEOFFRAY: Gondola.
SETH LADD: I love the
Zurich office.
It's a very, very cool office.
NICOLAS GEOFFRAY: Yeah, it's
nice to hang out here.
SETH LADD: Well thank you
for taking the time.
So some really interesting
developments over the past
couple weeks.
So we should start off with
where do you normally work,
and what project
do you work on?
NICOLAS GEOFFRAY: I normally
work in Aarhus, Denmark.
That's where lots of Dart
stuff is happening.
And I'm working on dart2js.
That's the compiler that
compiles Dart programs to
JavaScript.
SETH LADD: And the dart2js
compiler itself is written in
Dart, correct?
NICOLAS GEOFFRAY: It is.
SETH LADD: So that's
pretty cool.
So we're dog fooding our own
language and tools to make
more tools.
I like that.
We had a very interesting
development last week.
Why don't you go ahead and share
your screen, and we'll
talk about what happened.
NICOLAS GEOFFRAY: Sounds good.
Start screenshare.
So here you can see
what happened.
SETH LADD: Ah, look at
those healthy bumps.
So we're looking at the
performance charts you can
find on dartlang.org, where we
track the performance of some
well-known benchmarks across
the V8 world, which is our
JavaScript engine; the Dart VM
world, which is the teal line
on the top; and dart2js, which
is the purple line.
And Nicolas, what happened
there last week?
NICOLAS GEOFFRAY: You can see
the small bumps here.
I don't know if you can follow
me with the mouse.
But what actually happened is
that now we have better
tracking of types of fields and
parameters given to a method.
That enables us to do better
optimizations inside methods.
So we know what kind of fields,
what kind of types
we're getting in the field, and
what kind of types we're
getting when we're in a method
for a parameter.
So the small bumps that
come into little--
I mean, like this was last week,
this was a few days ago.
It's because we got better
improvements on that type
inferencing, as we call it.
SETH LADD: So it looks--
and what's really interesting,
maybe you can explain this to
me, is the code which is the
purple line here, that is
output by dart2js--
which is outputting
JavaScript--
is actually running
faster than V8.
Now of course when we run the
output JavaScript on V8--
I mean, what are we
looking at here?
How can V8 run faster than V8?
NICOLAS GEOFFRAY: So this
is pretty funny.
You would guess that we would
run at 100% of V8 ideally.
That's our goal in
the dart2js team.
What is happening is that we're
getting pretty lucky
with the V8 compiler, because
we're reaching a nice path in
the V8 compiler that
allocates--
that does better register
allocation, things like that.
So that's one explanation.
A second explanation is that
we're doing pretty aggressive
aligning because we have
better knowledge
of the whole program.
And that knowledge is kind of
hard to gather with V8 when it
runs the JavaScript version.
SETH LADD: OK, so the
purple line isn't V8
running faster than V8.
It's the outputted code from
dart2js is just more
intelligent than the handwritten
benchmark code
that V8 is running as the
benchmark by which all other
benchmarks are measured.
NICOLAS GEOFFRAY: Yeah.
That's correct.
SETH LADD: That's awesome
So this is really cool.
And so everyone can check this
out, dartlang.org/performance.
I would say expect more
benchmarks soon.
There's only two operating now,
DeltaBlue and Richards.
And from what I guess, your
team is just getting
started with this.
From what I'm hearing, you're
even being a little
conservative about how you
apply these inferences.
So what's your feeling for the
runway here in terms of just
general dart2js performance?
Do you have more work to do?
NICOLAS GEOFFRAY: We have
a lot of work to do.
If you look at the benchmarks
DeltaBlue and Richards, we
cover a lot when it comes to
doing type inferencing.
There are some other benchmarks
that we're still
working on where the type
inferencing still needs some
improvements, and
working on that.
SETH LADD: Cool.
Well I know you prepared a
couple slides here to walk us
through exactly what global
type inferencing means.
Do you mind giving us kind of
a tour behind the scenes on
how you guys achieved
these speed bumps?
NICOLAS GEOFFRAY: Sure, so
a small explanation.
The global type inferencing
looks at you whole program an
looks at assignments to fields,
assignments to local
variables, parameters
of methods.
So every time you call a
method, we look at what
parameters you call it with.
And when you gather all that
information, at the end, you
actually calculate or compute
the types of the fields and
the types given to parameters.
And in order to be correct,
you actually need to have
global knowledge.
And that's what we have when
we compile the Dart
application to JavaScript.
SETH LADD: And it's
global now.
What about the Dart--
and by the way, all
we see is your slide.
So if you want to stop
screensharing for a minute,
I'll ask you a couple
questions.
Then we'll jump back
to the slides.
But what is it about
Dart that--
there you go.
Hey.
What is it about Dart
that allows you
to do global analysis?
Why can't we do this--
why can't V8 do this
in JavaScript?
NICOLAS GEOFFRAY: What happens
in JavaScript is that you can
download JavaScript
code on demand.
You can dynamically extend
your application with new
calls, new assignments
to fields.
And suddenly what you thought
you knew about
the world gets extended.
In V8 land, when it's a VM doing
optimization, it needs
to de-optimize.
Because now it sees, oh, this
field is an int and not just a
string or something like that.
So that's the difference.
With Dart, we actually have
knowledge of the whole
application.
There's no dynamic loading, and
it's pretty structured.
So we know when we analyze
the program what kind of
[INAUDIBLE] the fields
will have.
SETH LADD: For everyone who's
just joining us, we're here
chatting with Nicolas Geoffray,
one of the engineers
on the dart2js project, who
normally works in Aarhus,
Denmark, but today is joining
us in a gondola
in the Zurich office.
And we were chatting about some
of the recent performance
bumps that he and his team have
landed which have shown
some pretty nice improvements
with the
benchmarks that we're tracking.
We're talking about global type
inferencing and what the
Dart language allows us to do
above and beyond maybe what
the JavaScript or V8 can
do to get some of
these performance bumps.
But one thing that I like to
explain to people about Dart
is that it has a known
starting point.
Every Dart program starts
with the main function.
And from there, the program--
the whole program analysis
can start by holistically
understanding the complete
boundaries of that program.
And it sounds like you're able
to take advantage of this by
doing a global type inference
across the entire program.
NICOLAS GEOFFRAY: One thing I
should probably also add is
that in JavaScript,
it's so dynamic.
There's lots of functionalities
like eval, and
different ways of changing
the value of a field.
And that makes it very difficult
for a static
analysis to actually track
types of variables.
SETH LADD: Right.
And so one thing I should
probably ask though is, we
keep mentioning this global
type inferencing.
My understanding, of course,
is Dart has an
optional type system.
Now for everyone following along
at home, why don't you
just respect those
type annotations?
I put those in there.
But why you have to go to a
global type inferencing?
NICOLAS GEOFFRAY: The type
system in Dart is optional.
You don't have to use it.
And we actually have--
Dart actually has two modes
for running applications.
One is called checked
mode, and one is
called unchecked mode.
In checked mode, the type
annotations actually have
meaning, that we will check that
the types match what you
put in a variable.
So if you string a equals 2,
we'll check that and produce a
runtime error.
In unchecked mode, we don't
look at that limitations.
We just go through.
So string a equals 2?
Fine, we'll continue.
And that's the main reason
we do not use those type
annotations for optimizing.
It's like, if you see
string a, well,
nothing will make sure--
in non-checked mode, nothing
will make sure that your
variable a will hold a string.
You can put anything in it.
So you need to analyze every
assignment to that a variable
to make sure it gets
that type.
SETH LADD: Awesome.
And as a developer, I actually
really like the way Dart does
this, in that I don't feel
like I have to appease a
ceremonial type checker just
to get my program to run.
And now that I see that the
engineers, like the guys in
the dart2js team, are able to
analyze my program for me and
infer these types anyway, I
still feel like the tools and
runtimes can take
advantage of--
if I use int everywhere, then
you're going to start assuming
that's an int and take advantage
of that optimization
by assuming it's an int.
This a good time to jump over
to the slides that you have,
because I'm really curious to
see actually how this works.
So can you walk us through
a little bit?
NICOLAS GEOFFRAY: Yeah.
I've taken a small
code snippet of
the DeltaBlue benchmark.
Here you have the slides.
SETH LADD: I see me.
NICOLAS GEOFFRAY: Oh,
you only see you.
SETH LADD: Yep.
NICOLAS GEOFFRAY: Screenshare.
Let's try again.
Desktop.
There it is now.
SETH LADD: OK.
I see it.
Fire it up.
NICOLAS GEOFFRAY: Present.
SETH LADD: And so before you
jump into this though, let's
talk a little bit about the
benchmark that everyone's
talking about, DeltaBlue.
Where did this thing
come from?
What does it do?
Do you know anything about
its lineage or history?
NICOLAS GEOFFRAY: Not really.
So DeltaBlue is a pretty popular
benchmark that I think
started with maybe Smalltalk--
I'm actually not sure--
and got ported to Java,
and ported to
JavaScript by the V8 team.
And now it's been ported to Dart
by the same-- well, the
former V8 team, and
now the Dart team.
It's a fairly--
it's an object-oriented
benchmark, uses typical
objects, and object dispatch.
So it's the kind of benchmark
that should represent a real
application.
SETH LADD: OK, cool.
So it has a long lineage that's
been ported many times.
And it's really stressing an
object-oriented type of system.
NICOLAS GEOFFRAY: Yes.
So if you write applications
really object-oriented, it
should be pretty similar.
SETH LADD: So what are
we looking at here?
NICOLAS GEOFFRAY: This is a
method written in Dart of the
DeltaBlue benchmark.
It's one of the hottest methods
of the benchmark.
I've taken a snipped.
And you can see it's
pretty simple.
You've got a method with
two parameters.
And walk over the elements of
the list and check if it
satisfies some constraint, and
then add it to another list.
SETH LADD: OK, pretty
straightforward code here.
NICOLAS GEOFFRAY: The next slide
shows what we used to
generate back then.
That means like two weeks ago.
SETH LADD: We can
see your mouse.
So if you want to move your
mouse to point to areas that
you're talking about,
go for it.
NICOLAS GEOFFRAY: Oh, sure.
That's revision 19850, back
when we didn't have global
type inferencing.
And you can see it's
not looking as
good as the Dart version.
There's a lot of checking, like
you were checking if a
call to a length getter on some
variable gives you a number.
And if it doesn't, we actually
jump to a method
that will handle it.
You can see that before,
we used the Dart
version as a for loop.
Now we can just have a while
loop because we have all these
statements that cannot be
expressed in a for loop.
We need to break here
to break the loop.
So it doesn't look as nice
as the Dart version.
And today what we generate is
actually pretty close to the
Dart version, with a for loop,
and just a check of the
condition, and adding to a new
collection, very similar to
that Dart version.
SETH LADD: Now help me
understand for the second
slide, the original
JavaScript.
Why did you have to move
to a while loop and
put all those bailouts?
NICOLAS GEOFFRAY: The reason we
have those bailouts is to
actually have good performance
when running on top of
JavaScript.
If you were not to have all
these checks here, we couldn't
omit this less than
directly, like
JavaScript built-in operators.
Dart has different semantics.
And every object actually has
its own less than method.
So it's not like we can use
the JavaScript built-in
operator for that.
SETH LADD: Right, because at
that point you don't know it's
actually an int.
So first you'd say, is this
thing really an int.
If so, great.
Go ahead and use less than.
Because in Dart code, you have
operator overriding.
You could have any object--
or, sorry, any class implement
its own version of less than.
NICOLAS GEOFFRAY:
That's correct.
And you can see that I actually
have another check
here, which is always
v.get$constraints, an array.
And if it's not then I need to
go again in a bailout in the
non-optimized version.
And if it is, then great.
I can do typical array indexing,
like transcript
array indexing, and call--
yeah, so typical array
indexing here.
SETH LADD: OK, so the original
code has to accommodate a very
dynamic world, because
he doesn't know
these objects can be.
NICOLAS GEOFFRAY: Yeah.
He doesn't know.
SETH LADD: But, the new world.
NICOLAS GEOFFRAY: The new world,
which does a better
inferencing on variables,
does know all of this.
You can see it knows that t1
here is a JavaScript array.
So v.constraints is a
JavaScript array.
So it can just use the
built-in less than of
JavaScript.
Again, it uses the built-in
indexing operator here.
SETH LADD: That is so cool.
OK, so the new world.
How do you actually go about
analyzing and say, OK, i is
really an int now.
It looks like that's the
major change, isn't it?
Now you've been able to analyze
the program and say I
know for a fact that some of
these variables point to
objects of these types so I can
eliminate all bailouts.
That's basically what's
happening, right?
NICOLAS GEOFFRAY: That's
basically what's happening.
We have better information of
the types of some fields.
And we can do better.
I'll actually go through some
of them, just to show the
difference of some statements
of the [INAUDIBLE] code.
This is the old version.
And you can see that we're
actually calling a getter.
This is calling a getter
method on v. And that's
because we have no--
we don't know what v is.
So the Dart code that used to
do v.determinedBy will get
translated to
v.get$determinedBy.
Because we don't know if it's
a field or a getter.
But with the new type
inferencing, we actually know
that v is an object that has
a field and a getter called
determinedBy.
SETH LADD: Oh, that's so cool.
NICOLAS GEOFFRAY: So we can just
inline the field access,
like JavaScript field access.
We know it won't
throw an error.
And we know v has that field.
So that's one improvement.
A second improvement
is the loop itself.
So I told you that before we
couldn't generate a for loop
because of all these checks.
These statements don't hold
in the for [INAUDIBLE]
condition update typical loop.
But with the new version, you
don't have these statements.
You're not checking anymore.
So you can actually just
generate something very
similar to the Dart code, which
is, oh, I'm fetching
constraints out of v. But
I know that the field
constraints of v is a
JavaScript array.
So I can just iterate
over the lengths.
And that makes it very easy
to generate a for loop.
SETH LADD: And not only is this
faster code, but it's
also much easier to read.
So now the debugging of the
generated code, to me at
least, gets a lot easier.
NICOLAS GEOFFRAY: Yeah.
If you look at the generated
code and the original code, it
looks very similar.
So you actually can make sense
of, oh, I got an error here.
How does that map
to my Dart code?
Another improvement is all
this checking again.
You're checking if t1 is
actually an array.
And you're doing--
so that's the check, right?
And since you don't know if i is
in the range of the array,
you do a range check here.
And then you do the access,
because you know it's a
JavaScript array.
You know that it's in bounds,
so you don't throw an error.
And you can just access
directly.
Because of the new type
inferencing, we now know that
t1 is a JavaScript array.
We know that i is in between
0 and t1.length.
So we know it's not
out of bounds.
So we don't need to emit
a bounds check.
And we just generate the
[INAUDIBLE] access.
SETH LADD: That's huge.
And one of the differences
there, thinking about the
original code, is the difference
in behavior in a
Dart list and a JavaScript array
when you access an index
out of bounds.
In Dart you'll get a--
forgive if I don't get the
right name, but it's like
index out of range error?
NICOLAS GEOFFRAY: I think
that's changed
to reg error now.
SETH LADD: OK.
You'll get a range error.
But you'll get an actual
exception thrown when you try
to access an index that's out
of the range of the list.
But in JavaScript, I believe
you'll just get undefined.
So the original Dart code had
to match that behavior.
But it looks like now you're
able to be even smarter and
say well, I know ahead of time
if these accesses are actually
out of range.
And if I know that, I don't
need to put that check in.
That is great.
NICOLAS GEOFFRAY:
That's correct.
If JavaScript was to throw an
error when we got out of
bounds, we wouldn't need
this code here.
But it doesn't.
And what happens is you just
get undefined out of it.
And then you maybe get
an error later.
But with Dart, you do get the
bounds check early, just
before the access.
But in that case, you actually
don't need it, because you
know i is within the range.
SETH LADD: OK, I like that.
NICOLAS GEOFFRAY: I'm sorry?
SETH LADD: I like what
I see so far.
This is great.
NICOLAS GEOFFRAY: I
think that's not
the last, but almost.
That's another--
that's the last optimization
that triggered the jump, the
bump in the graph.
It's knowing that when you're
doing an equals check--
so the original code is c double
equal determining.
And when dart2js knows that
you're actually just doing an
identity check, because that
equals results in the object
equals in Dart.
So you could just emit the
definition of the identity
check in Dart, which
is pretty complex.
But the intent is that the
[INAUDIBLE] equals doesn't
have to check for null.
So if you pass a null, if
the receiver is null--
I'm sorry.
Let me revert.
What I'm saying is that in
dart2js, we actually have two
nulls, because of some
dumb problems with
interaction with the DOM.
One is undefined,
just undefined.
And the other is JavaScript
null.
So we cannot just use triple
equal for checking if two
things are identical.
We need to use double equal.
That's what's happening here.
c could be undefined of null.
In that case, we need to
check if determining is
undefined or null.
And that's what's
happening here.
The most interesting is that
here, it's the identity check.
And we don't need to go
through a method.
We just use the JavaScript
identity check.
SETH LADD: How does dart2js know
or infer that I'm doing
basically an identity check?
NICOLAS GEOFFRAY: It knows that
c, the [INAUDIBLE] equals
on c is the wanted object.
SETH LADD: OK.
So this one, this particular
thing, wouldn't work if I
implemented my own equals
equals, of course.
NICOLAS GEOFFRAY: So if you
implemented your own, and the
type inferencing would know what
kind of variable, what
type that variable is.
Then you would do actual direct
call of that method, of
that operator equal of yours.
In that case here-- before,
it actually didn't know
what c could be.
Because of the way we generate
code, we cannot just call a
method on c.
If c was to be an integer, for
example, I mean, it's a
JavaScript integer or number.
It's not like you can call
something on it.
So we need to code local
methods that will
do all these checks.
But now we actually know
what c could be.
And we know that c, that you're
just doing an identity
check on c.
And you only need to emit
this code instead.
SETH LADD: Great.
NICOLAS GEOFFRAY: And the last
optimization I'll show you is
this check.
So the semantics in Dart of an
if check is that the condition
must evaluate true.
If it evaluates to anything
else, it's false.
And that's very different than
JavaScript, where lots of
things evaluate to true--
1, non 0, non null,
non undefined.
SETH LADD: Right, many
truthy values.
NICOLAS GEOFFRAY: Exactly.
And Dart is very different, that
you have to be true to
actually pass an if test.
We generate a lot of triple
equals true when doing calls
in if checks, because we
don't know what this
method actually returns.
With the new type inferencing,
we know that all the
isSatisfied methods
in the benchmark
always return the Boolean.
It returns either false, the
JavaScript false, or the
JavaScript true.
So we don't need to compare.
If that evaluates to false,
then the condition will be
false and we won't go
in the if block.
If it evaluates to
true, then fine.
It will continue.
SETH LADD: Yeah, this code
is so much smarter.
Good job.
NICOLAS GEOFFRAY: That's it,
comparing the old version of
what we generated and the new
version of what we generated.
I have a slide of what is the
actual implementation in the
JavaScript benchmark.
SETH LADD: OK, so this is what
V8 has been running as its
version of DeltaBlue
for many years.
This is the one we
measure against.
NICOLAS GEOFFRAY: Yes, that's
the one idea of what is called
now the Octane benchmark.
This is the Dart version.
No.
This is not the Dart version.
That's the dart2js version.
Let me check if I have a Dart
version close to it.
No I don't.
SETH LADD: I think we can flip
back and forth between the
dart2js version and the
original V8 version.
Because what's really
interesting to me is how did
dart2js generate a version of
that method that's faster than
the handwritten.
Which, I guess most people
would assume that the
handwritten benchmark is always
going to be the fastest.
So I think you you've got
a couple areas you're
going to point out.
NICOLAS GEOFFRAY: Yeah.
So what's happening here,
actually I've highlighted what
is happening.
If you look at those statements
where you're doing
something on cc and call,
the call variable--
how to start?
The JavaScript benchmark needs
to add some behavior to the
JavaScript array.
There are multiple ways to
add new behaviors to
a JavaScript array.
You can drop it so you have your
own object that grabs a
JavaScript array.
And you do calls on
that object, and
you get that behavior.
Another way is to
monkey patch.
That's adding new
methods to the
JavaScript array prototype.
But that latter solution
doesn't really scale.
If you start to monkey patching
in one component of
your application, then monkey
patching in another component
could just not work, because
you're adding the same method
name with different
parameters.
SETH LADD: When you mix these
two worlds, you don't know
what's going to happen.
NICOLAS GEOFFRAY: Yes.
So I guess that's the reason why
the JavaScript benchmark
wraps the JavaScript array in
order to add new behavior, so
the size, the add, and the add
under the new behavior.
There's another method in the
benchmark that moves something
from your array that matches
a pattern, or
something like that.
The benchmark actually wraps
a JavaScript array.
And that's what Dart is also
doing with its list class.
The list class in Dart has lots
of behavior, not just the
JavaScript array behavior.
And what dart2js does is it
compiles a list object to a
JavaScript array.
But in order to have that new
behavior in the JavaScript
array, it uses that
functionality called
interceptors that will hold
this new behavior.
And that's the reason why
we could just generate a
JavaScript array out of
a list, a Dart list.
And when you call methods
that are on the list--
like filter--
well now it's called
RemoveWhere--
all these methods are in list
in a simple class called
[? iterable. ?]
All these methods will actually
go through an
interceptor that will implement
the behavior.
SETH LADD: Let's see
the version that
dart2js spits out again.
I think that will make
it more clear.
NICOLAS GEOFFRAY: Since we
actually use a JavaScript
array for a Dart list, the
dart2js knows that you can
actually just do an
array access, a
JavaScript array access.
Like here, so you notice at t1
is a Dart list that will map
to a JavaScript array.
So you can just do a direct
JavaScript array axis.
And the same for call here.
It knows that it's
a Dart list.
That means it knows it's a
JavaScript array at runtime.
So you can just call the push
method, which is something
that is on the JavaScript array
prototype by default.
SETH LADD: And you can do this
because you've globally
analyzed the program and
you know what t1 is.
NICOLAS GEOFFRAY: Exactly.
SETH LADD: That is awesome.
That is so cool.
NICOLAS GEOFFRAY: And we also
know that all the [INAUDIBLE]
of add constraints consuming
to pass an array
here, or a Dart list.
SETH LADD: So that's actually
really good key point.
Again, when we say global type
inferencing, you mean not just
obviously inside a function, but
also everyone, and we mean
everybody who calls into
this function.
You know what they're passing
in, so you make a whole bunch
of assumptions then inside
the function.
NICOLAS GEOFFRAY: Yeah.
That's correct.
SETH LADD: Yeah, cool.
That to me sounds like one of
the major differences between
how far V8's able to go and how
far dart2js or the VM is
able to go, based on--
we really have a closed world
assumption when we're thinking
about Dart applications.
NICOLAS GEOFFRAY: That's
basically it.
And since it's very
structured, it's
very easy to analyze.
Well, it's relatively
easy to analyze.
It's definitely easier
than JavaScript code.
SETH LADD: So here's an
interesting point.
Your global type inferencing
system does not respect type
annotations at all, due to the
semantics of the types or the
type annotations.
So I means I could write a
program with zero type
annotations and still get the
exact same benefits from
dart2js today.
NICOLAS GEOFFRAY: Yeah.
Same benefits, and the same
applies to the VM.
SETH LADD: Yeah.
That's a great point.
NICOLAS GEOFFRAY: The VM
doesn't look at type
annotations either.
So type annotations is really a
tool for the developer to do
refactoring and share some code
with other developers.
SETH LADD: So it sounds like
if I as a developer want to
take advantage of some of these
nice new inferencing
optimizations, just make sure
that I assign a variable the
same type all the time, and
dart2js will respect that.
NICOLAS GEOFFRAY: Yeah.
There are some couple of things
that will make dart2js
very happy.
So if you start assigning the
same thing to a variable or a
field, it will be able to apply
optimization based on it.
SETH LADD: So for everyone
following at home, use final
and don't change field types,
and you'll be much happier.
NICOLAS GEOFFRAY: And if you
have a field that is supposed
to hold a number, make sure
it holds a number.
And it can never be null.
So the Dart VM--
it shouldn't affect
the Dart VM much.
But for dart2js, it's very
important because of what's
happening in JavaScript.
In JavaScript, when you
do null plus 42, you
actually get 42.
To the null gets
converted to 0.
SETH LADD: That's logical.
NICOLAS GEOFFRAY: In Dart, null
plus should throw you a
null pointer exception.
So if dart2js knows that this
field is always a number, it
won't have to do any checking.
SETH LADD: So what I'm thinking
about now is when I
have classes that have fields
that should be numbers, make
sure I initialize them in
the initializer list.
NICOLAS GEOFFRAY: In the
initializer list, or where the
field is declared.
It makes the type
inferencing--
it makes the life of the type
inferencing a lot easier.
SETH LADD: Wow, that
is a great tip.
I was going to ask is there
anything else that I need to
do as a developer to write code
in a special way to take
advantage of this.
And so the good tip is, if I'm
dealing with numbers, make
sure they're always initialized
to a number, and
don't change them from a number
to something else.
NICOLAS GEOFFRAY: Yeah.
Keep your fields sane.
That's what you should say.
SETH LADD: Well I really,
really appreciate this.
This video is recorded.
We're going to post it up
for everyone to watch.
And so I am very encouraged
and happy to see the bumps
that you and your team are able
to push out for dart2js,
so excellent work there.
Can we expect more benchmarks?
And what we expect in terms of
how much you're rolling out
this type inferencing?
NICOLAS GEOFFRAY: So
it just started.
It's been two weeks since we
started on type inferencing.
And right now it's
pretty naive.
There's a lot of improvements we
know we can do, except that
it gets more and more complex
to implement.
We still have the same bar.
We were generating JavaScript
code, and what we want is
actually to be as fast as
handwritten JavaScript code.
And we're getting
closer to that.
If you look at DeltaBlue,
that's what's happening.
We have some other benchmarks,
and we're getting close to the
same performance.
They need more work,
obviously.
The reason why they're not
public yet, those benchmarks,
is because publishing
a new benchmark is--
I mean, we need to make
sure they're relevant.
And we need to make sure that
they apply to JavaScript and
Dart, and both versions have
equivalent functionalities and
stuff like that.
So it's not that [INAUDIBLE] to
publish those benchmarks.
SETH LADD: Right, but I get the
sense we'll see more over
time as we've tested them out
and making sure they're
relevant and correct.
NICOLAS GEOFFRAY: Yes.
I mean, the V8 benchmark suite
that is now Octane benchmark
suite, it took some time
to publish it.
It's not super obvious that all
those benchmarks actually
are relevant initially.
SETH LADD: Well I like
what I see so far.
Dart developers can take
advantage of this today.
This is code that has
been checked in.
When you get the dart SDK and
you compile the JavaScript,
they're going to see these
improvements, or at least the
beginnings of these
improvements.
So this stuff is real
and available today.
Well, thank you on the behalf
of the Dartisans community.
Nicolas, thanks for joining
us today and
preparing these slides.
It was a great walkthrough, and
I really appreciate it and
learned a ton of stuff myself.
So hopefully we'll have you back
again later when we've
got other cool stuff to show
from the dart2js world.
NICOLAS GEOFFRAY: My pleasure.
Maybe tomorrow.
SETH LADD: You guys are fast.
Well thank you very much and
we'll see you next time.
Bye, Nicolas.
NICOLAS GEOFFRAY: See you.
