1. Include in standard library or build in?
I can see a lot of proposals for additions in the standard library, specially in
the field of basic sequence manipulation.
This will save typing, and spare the bugs that come with reinventing the wheel.
Good.
However, sometimes, it may be more efficient to implement some routines as
built-ins rather than in include files. One of the main reasons is that checks of
various kinds are performed twice or more, and data which is available at run
time is being queried by several pieces of code, for more IL opcodes and no
benefit.
For very basic routines (I have head(), tail() and mid() in mind, and perhaps a
couple others), we should expertise whether moving them inside the interpreter
might not help the language by increasing efficiency, and in some cases making
code leaner instead of adding layers on top of one another.
This could be a Rule #6: Check the compared benefits before choosing between
stdlib and backend (applies to basic functionality only).
CChris
2. Re: Include in standard library or build in?
CChris wrote:
>
> I can see a lot of proposals for additions in the standard library, specially
> in the field of basic sequence manipulation.
>
> This will save typing, and spare the bugs that come with reinventing the
> wheel.
> Good.
>
> However, sometimes, it may be more efficient to implement some routines as
> built-ins
> rather than in include files. One of the main reasons is that checks of
> various
> kinds are performed twice or more, and data which is available at run time is
> being queried by several pieces of code, for more IL opcodes and no benefit.
>
> For very basic routines (I have head(), tail() and mid() in mind, and perhaps
> a couple others), we should expertise whether moving them inside the
> interpreter
> might not help the language by increasing efficiency, and in some cases making
> code leaner instead of adding layers on top of one another.
>
> This could be a Rule #6: Check the compared benefits before choosing between
> stdlib and backend (applies to basic functionality only).
>
> CChris
I disagree. Let's focus on getting a coherent library first, then we can argue
whether some functions should be moved to the backend or not.
--
A complex system that works is invariably found to have evolved from a simple
system that works.
--John Gall's 15th law of Systemantics.
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
3. Re: Include in standard library or build in?
Jason Gade wrote:
>
> >
> > However, sometimes, it may be more efficient to implement some routines as
> > built-ins
> > rather than in include files.
>
> I disagree. Let's focus on getting a coherent library first, then we can argue
> whether some functions should be moved to the backend or not.
I agree that some functions may be better suited for internal, however, I agree
with Jason also, let's concentrate on getting functions first. Then, in future
releases, we can move "important" ones into the interpreter.
We shouldn't break anything by doing that at a later date.
--
Jeremy Cowgar
http://jeremy.cowgar.com
4. Re: Include in standard library or build in?
CChris wrote:
>
> I can see a lot of proposals for additions in the standard library, specially
> in the field of basic sequence manipulation.
>
> This will save typing, and spare the bugs that come with reinventing the
> wheel.
> Good.
>
> However, sometimes, it may be more efficient to implement some routines as
> built-ins rather than in include files. One of the main reasons is that
> checks of various kinds are performed twice or more, and data which is
> available at run time is being queried by several pieces of code, for more
> IL opcodes and no benefit.
>
> For very basic routines (I have head(), tail() and mid() in mind, and perhaps
> a couple others), we should expertise whether moving them inside the
> interpreter might not help the language by increasing efficiency, and in
> some cases making code leaner instead of adding layers on top of one another.
>
> This could be a Rule #6: Check the compared benefits before choosing between
> stdlib and backend (applies to basic functionality only).
Yes, I fully agree with this. I'm doubtful that the head/tail type routines
will have too much benefit (but would be happy to be proved wrong). I think
a likely source for this sort of work is for removing elements from a sequence.
Especially for big stuff, all we'd need to do is deref the elements going
away, move the memory of the remaining, and update the padding and length
info on the sequence.
Matt
5. Re: Include in standard library or build in?
If I understand the interpreter correctly (and I probably do not), it's a large
switch statement? Doesn't a switch statement like this have a large % of jump
offset errors, thus, the more items you add to the switch the slower the switch
actually gets?
Now... after saying that, let me prefix it with, I've only done very minimal
reading about how internals of interpreters work. I've written some very small
domain specific interpreters, but nothing at all even close to as advanced as
Euphoria. Therefore, what I understand above may be totally off base.
--
Jeremy Cowgar
http://jeremy.cowgar.com
6. Re: Include in standard library or build in?
Jeremy Cowgar wrote:
>
> If I understand the interpreter correctly (and I probably do not), it's a
> large
> switch statement? Doesn't a switch statement like this have a large % of jump
> offset errors, thus, the more items you add to the switch the slower the
> switch
> actually gets?
>
> Now... after saying that, let me prefix it with, I've only done very minimal
> reading about how internals of interpreters work. I've written some very small
> domain specific interpreters, but nothing at all even close to as advanced as
> Euphoria. Therefore, what I understand above may be totally off base.
This is part of the magic of what Rob's done--at least in Watcom, gcc uses
an easier to understand ability to hack goto. If you build with -DINT_CODES
or whatever the switch is, you'll get a big switch statement. But Rob
stores the jump table and moves the instruction pointer (goto in gcc,
by literally changing esp in Watcom) to go to the next statement.
Matt
7. Re: Include in standard library or build in?
Matt Lewis wrote:
>
> This is part of the magic of what Rob's done--at least in Watcom, gcc uses
> an easier to understand ability to hack goto. If you build with -DINT_CODES
> or whatever the switch is, you'll get a big switch statement. But Rob
> stores the jump table and moves the instruction pointer (goto in gcc,
> by literally changing esp in Watcom) to go to the next statement.
>
Matt,
So your saying that adding functions to Euphoria does not affect it's overall
speed? i.e. If you were to add 1,000 more functions (just an example people, do
not fear!), it would not change execution speed?
--
Jeremy Cowgar
http://jeremy.cowgar.com
8. Re: Include in standard library or build in?
- Posted by Matt Lewis <matthewwalkerlewis at gm?il.c?m>
Apr 28, 2008
-
Last edited Apr 29, 2008
Jeremy Cowgar wrote:
>
> So your saying that adding functions to Euphoria does not affect it's overall
> speed? i.e. If you were to add 1,000 more functions (just an example people,
> do not fear!), it would not change execution speed?
Well, it would definitely increase startup speed. It could affect execution
speed due to increased cache misses, or something, but it's probably not
as highly correlated as it would be with a massive switch statement.
Matt
9. Re: Include in standard library or build in?
- Posted by CChris <christian.cuvier at ag??culture.gouv.fr>
Apr 28, 2008
-
Last edited Apr 29, 2008
Jeremy Cowgar wrote:
>
> If I understand the interpreter correctly (and I probably do not), it's a
> large
> switch statement? Doesn't a switch statement like this have a large % of jump
> offset errors, thus, the more items you add to the switch the slower the
> switch
> actually gets?
>
The backend, once the code is properly converted and formatted, is a big switch
that executes VM opcodes sequentially.
If threaded code is enabled (works with some compilers only), then there is no
penalty in having a bigger switch, because all switch branches jump to the branch
corresponding to the next opcode.
Which "jump offset errors" are you talking about?
* Stack offset errors my be caused by a change of compiler version, and affect
c_func() and friends. You told us about such an issue with gcc 4.3 recently.
* Cache misses because of jumping too much around may increase with the size of
the switch statement. However, the most frequently executed statements will be
properly predicted and cached pretty often, so that the net effect will be very
much dampened. The CPU instruction cache size obviously matters too.
CChris
> Now... after saying that, let me prefix it with, I've only done very minimal
> reading about how internals of interpreters work. I've written some very small
> domain specific interpreters, but nothing at all even close to as advanced as
> Euphoria. Therefore, what I understand above may be totally off base.
>
> --
> Jeremy Cowgar
> <a href="http://jeremy.cowgar.com">http://jeremy.cowgar.com</a>
10. Re: Include in standard library or build in?
- Posted by Jeremy Cowgar <jeremy at cowgar?com>
Apr 28, 2008
-
Last edited Apr 29, 2008
CChris wrote:
>
> Which "jump offset errors" are you talking about?
>
It was my understanding that a switch statement would goof 50% of the time and
have to track up or down to find the right case. I might have totally
misunderstood what I was reading, but that's the impression I got.
That's what I was speaking about. I probably used the wrong term for it.
--
Jeremy Cowgar
http://jeremy.cowgar.com
