Dynamically Jitting methods?

  • Thread starter Thread starter codymanix
  • Start date Start date
C

codymanix

If I pass an IComparer to the Array.Sort method is the Jitter able to inline
the comparer-method dynamically?
Theoretically it should, but does it actually do it?
 
codymanix said:
If I pass an IComparer to the Array.Sort method is the Jitter able to inline
the comparer-method dynamically?
Theoretically it should, but does it actually do it?
Click to expand...

No - the code for Array.Sort will only be JITted once, and it can't
rely on you always calling it with the same implementation of
IComparer, so it can't inline the comparisons.
 
If I pass an IComparer to the Array.Sort method is the Jitter able to
inline
No - the code for Array.Sort will only be JITted once, and it can't
rely on you always calling it with the same implementation of
IComparer, so it can't inline the comparisons.
Click to expand...


That is exactly the point! Since the Jitting (unlike compilation)is done at
runtime is *can* determine the runtimetype of the IComparer passed and rejit
it. That means jitting of the Array.SortMethod could be done *every* call of
the method but the Jitter may determine to rejit only if the Arraylenght is
bigger than a certain value so that the rejit is worth it.

Additionally, already jitted instances of Array.Sort(IConparer comp) may be
cached in memory so that repeated calls of Array.Sort with the same
IComparer uses the cached version.
 
codymanix said:
That is exactly the point! Since the Jitting (unlike compilation)is done at
runtime is *can* determine the runtimetype of the IComparer passed and rejit
it.
Click to expand...

No, "rejit" is the key word here: JITting is only done once per method.
That means jitting of the Array.SortMethod could be done *every* call of
the method but the Jitter may determine to rejit only if the Arraylenght is
bigger than a certain value so that the rejit is worth it.
Click to expand...

It could be, but the current implementation certainly only JITs once
per method.
Additionally, already jitted instances of Array.Sort(IConparer comp) may be
cached in memory so that repeated calls of Array.Sort with the same
IComparer uses the cached version.
Click to expand...

Hmm. Even HotSpot (the Sun JVM which *does* JIT multiple times) doesn't
take that kind of approach. It rejits either once it's noticed that the
method has been called frequently, and does it again with more
optimisation, or if the circumstances have changed (e.g. a virtual
method has been overridden, so an optimisation elsewhere is no longer
valid).

There are various penalties associated with JITting, and while what
you're suggesting may well be possible, I suspect it wouldn't be
beneficial in the long run. (It would also add significantly to the
complexity of the JIT, which would have stability implications.)
 
There are various penalties associated with JITting, and while what
you're suggesting may well be possible, I suspect it wouldn't be
beneficial in the long run.
Click to expand...

Not beneficial? Consider what happens sorting of an array of 100000 elements
where each comparison involves a method call!
(It would also add significantly to the
complexity of the JIT, which would have stability implications.)
Click to expand...

Maybe, but it would be great: This could be one of the things where a
jitcompiled language can be much faster than C++!
 
codymanix said:
Not beneficial? Consider what happens sorting of an array of 100000 elements
where each comparison involves a method call!
Click to expand...

And then imagine JITting every method call you ever make - or running
analysis of every method to see whether or not to JIT it every time.
Maybe, but it would be great: This could be one of the things where a
jitcompiled language can be much faster than C++!
Click to expand...

Maybe - or maybe it would be really slow due to JITting time. Or maybe
it would be fast for *one* use, but slow for most other uses.
 
Back
Top