1. Include in standard library or build in?
- Posted by CChris <christian.cuvier at agri?ulture?gouv.fr> Apr 28, 2008
- 627 views
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?
- Posted by Jason Gade <jaygade at yaho?.c?m> Apr 28, 2008
- 634 views
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?
- Posted by Jeremy Cowgar <jeremy at cowg?r.co?> Apr 28, 2008
- 614 views
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?
- Posted by Matt Lewis <matthewwalkerlewis at ?mai?.com> Apr 28, 2008
- 611 views
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?
- Posted by Jeremy Cowgar <jeremy at cowga?.c?m> Apr 28, 2008
- 611 views
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?
- Posted by Matt Lewis <matthewwalkerlewis at gm??l.com> Apr 28, 2008
- 617 views
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?
- Posted by Jeremy Cowgar <jeremy at co?ga?.com> Apr 28, 2008
- 616 views
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
- 621 views
- 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
- 624 views
- 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
- 613 views
- 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