OpenEuphoria

Re: 64 bit euphoria

• Posted by jacques deschênes <desja at globetrotter.net> Apr 23, 2005
• 458 views

Robert Craig wrote:
> 
> Kenneth Rhodes wrote:
> > Robert Craig wrote:
> > > 
> > > There is hardly any asm in the Euphoria interpreter.
> > > The front-end is written in Euphoria.
> > > The back-end is 99.9% C. integers would likely become 63 bits 
> > > instead of 31. That could lead to some small compatibility issues,
> > > e.g. 
> > >   if integer(x) then ... 
> > > might have a different meaning.
> > > 
> > > It would probably not bother many people if a 
> > > simple declaration of:
> > >   integer x
> > > now allowed x to be 63 bits in size.
> > > 
> > > The use of 64-bit pointers internally by the interpreter 
> > > would probably not disturb most Euphoria programs. 
> > > It would just allow much larger sequences to be created.
> > 
> > Just how big of a performance hit would the interpreter take
> > if that 1% of the front-end code was written in C?
> 
> By "1% of the front-end code", 
> I assume you mean "0.1% of the back-end code".  
> 
> The main use of asm is for things that can't be expressed in C,
> such as pushing values onto a machine-level stack,
> not so much for speed. There would be little point in trying
> to eliminate the few lines of asm. It's just a minor nuisance 
> in porting and understanding the code.
>  
> > Also, it seems that hence forth the 64bit cpus will multi-core,
> > so shouldn't threads be a "must" feature for the next version of
> > Euphoria?
> 
> My main concern with threads isn't how to implement them,
> it's what are people going to do with them? Can any of the
> pro-thread people give some examples (that couldn't easily be done
> some other way, such as the Language Wars technique, or simply
> using multiple processes communicating via shared memory)?
> 
> Regards,
>    Rob Craig
>    Rapid Deployment Software
>    <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
> 


1) threads inside the same process take less resources than 2 processes
communicating.
2) a thread switching is faster (more efficient) than a context (process)
switching.

3) One obvious usage of threads is to get a more responsive applications. I hate
those situation where the application doesn't answer to mouse click (keypress) 
because it's caugth in a waiting loop for some network resource or something
else.
So when the application is designed with a thread for the user interface and a
thread for others cores,  the user interface keep responding.

4) why to bother designing threads machanics inside the application when it
already exist in the operating system in a more flexible an efficient way.

regards,
Jacques Deschenes