[ruby-core:32794] Re: ruby with near native speed

On Fri, Oct 15, 2010 at 04:34:46AM +0900, Haase, Konstantin wrote:
> Wouldn't that mean Ruby had to be thread-safe first?
No only thread-safe gc and atomic replacement of method are needed
> Konstantin
> 
> On Oct 14, 2010, at 21:25 , Ondナ册j Bテュlka wrote:
> 
> > Hello
> > 
> > Ideas from static typing thread correspond to ideas what to write as my thesis.
> > I have some ideas how today vm`s could be improved on x64. Now most of time x64 has idle cores so we could use them to: 
> > 
> > A shift from JIT to what I call continuous optimalization. JIT has slow startup time and generated code is not as fast as it could be.
> > While program runs we can spend on spare core unlimited time compiling better versions. We will save optimized versions on disk.
> > This allows time comsuming optimalizations and also previously impossible optimalizations.
> > 
> > Following optimalizations have this motto We can assume that sky is blue until somebody tell us its green.
> > Ruby is dynamic so anything can happen. But in 99% of cases it won't occur. In 1% cases we know how to fix it
> > Example is changing method body. Usually it doesn't happen. But if its changed we fix it by reverting all optimalizations that used given method.
> > 
> > Constant simulation:
> > 	As deterministic program with constant input must have constant output we can simulate constant part of code and replay side effects.
> > 	We get it further by assuming that certain rare conditions didn't happen (no method called in simulation was changed...).
> > 	If it happened we revert to original code
> > 	We can even assume that files modified long ago are constant. Again we check if they were modified and if they were we revert to original code.
> > 	Bit of care is required to not save constant gigabyte arrays to disk.
> > 
> > Almost static typing
> > 	As constant simulation typicaly expands all metaprogramming code to normal compiler can infer types of almost all variables through their lifetime.
> > 	With infered types we could optimalize functions further
> > 	It could be possible give flag to export source with annotated inferred types.
> > 	ruby object like C struct. If we can infer what variables can given class have we can store them in array of values.
> > 
> > Real profile information
> > 	Another advantage is that we get profiling informations from living system
> > 
> > Auto-tuning
> > 	For example assume we have algorithm which have optimalization flags O,P,Q and problem n auto-tuning allows by running algorithms in parallel determine
> > 	how set flags given problem size
> > 
> > Garbage collector	
> > 	Another nice thing could be garbage collector running on separate core.
> > 	Also use escape analysis where can be what freed without involving GC
> > 	
> > -- 
> > 
> > Post-it Note Sludge leaked into the monitor.
> > 
> 

-- 

manager in the cable duct