Re: Multitasking Preview Release
Vincent wrote:
> Cool Rob, I translated & compiled the source, and everything seems to run
> well. According
> to the documentation, the six tasking routines are implemented internally.
> That saves overhead
> from needing to include files, or time wrapping machine_func()/machine_proc()
> operations.
>
> With that said, I must ask why didnt just implement all the Euphoria routines
> completely
> internally from the start? That way there wouldnt be a need for include files
> for the
> Euphoria standard library, or having machine_proc(), or machine_func()
> routines. It's
> seems sort of like a mixed mess now, that could of been avoided.
It's a judgement call whether something should be implemented as
Euphoria code in an include file, or as a machine_proc/func special call,
or as a built-in routine.
Most things are not built-in because I don't want to have hundreds
of predefined symbols, many of them rarely used, using up space in
the symbol table, and forced on people who might want to use those
nice names for some other purpose. Overhead is not always important.
Some routines are rarely used in time-critical operations, and
some are so costly to run that saving a bit of overhead in
calling them would be meaningless. Some things like generic sort()
are written in Euphoria because they manipulate Euphoria values
more easily and without losing much speed compared to an internal
C implementation. I haven't heard of anyone tearing their hair out
over the speed of sort() in a real program.
I especially wanted task_yield() to be built-in, because
if it wasn't, people would feel more pressure to move it
out of loops. They might call it once per loop, rather than
once per iteration. Any overhead would make for less smooth
multitasking. This form of multitasking is as fundamental
as subroutine calling. It really should be in the guts
of the interpreter.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
|
Not Categorized, Please Help
|
|
