Re: Changes in the ESL papers
Matt Lewis wrote:
>
> Christian Cuvier wrote:
> >
> > > Pete Lomax wrote:
> > >
> > >>> I retract that. Code it for 2.5 and have a utility to convert to 2.4.
> > >
> >
> > Please don't.
> > s[legth(s)] and s[$] evaluate in different times. Converting 2.5
> > optimized code to 2.4 will work, but will lower efficiency. 2.4
> > optimized code will track the length of an ever expanding sequence to
> > scrape a few microseconds here and there. 2.5 optimized code won't. And
> > I don't know a converter smart enough to perform this change of
> > implementation.
> >
>
> For the trivial case, the code is identical. I used the disassembler that
> is part of ooeu to generate the following. I created a sequence:
> }}}
<eucode>
> sequence s
> s = repeat( repeat( 0, 10 ), 10 )
>
> ? s[$]
> <font color="#330033"></eucode>
{{{
...produces this </font><font
> color="#0000FF">for </font><font color="#330033">il code:</font>
> 15: 042 107 110 # LENGTH: [s:107] => [_temp_:110]
> 18: 025 107 110 110 # RHS_SUBS: [s:107] sub [_temp_:110] =>
> [_temp_:110]
> 22: 036 111 110 # QPRINT: [_temp_:110]
> }}}
<eucode>
> ? s[length(s)]
> <font color="#330033"></eucode>
{{{
...produces identical code:</font>
> 65: 042 107 113 # LENGTH: [s:107] => [_temp_:113]
> 68: 025 107 113 113 # RHS_SUBS: [s:107] sub [_temp_:113] =>
> [_temp_:113]
> 72: 036 111 113 # QPRINT: [_temp_:113]
>
> Now consider a more interesting, but still simple case:
> }}}
<eucode>
> ? s[$][$]
> <font color="#330033"></eucode>
{{{
...</font><font color="#0000FF">and
> </font><font color="#330033">we get:</font>
> 27: 042 107 110 # LENGTH: [s:107] => [_temp_:110]
> 30: 025 107 110 110 # RHS_SUBS: [s:107] sub [_temp_:110] =>
> [_temp_:110]
> 34: 042 110 112 # LENGTH: [_temp_:110] => [_temp_:112]
> 37: 092 110 112 112 # RHS_SUBS_CHECK: [_temp_:110] sub [_temp_:112]
> # => [_temp_:112]
> 41: 036 111 112 # QPRINT: [_temp_:112]
>
> Two calls to length, plus two RHS Subscripts. A simple, straightforward
> converter might change that to:
> }}}
<eucode>
> ? s[length(s)][length(s[length(s)])]
> <font color="#330033"></eucode>
{{{
...which would look like:</font>
> 77: 042 107 113 # LENGTH: [s:107] => [_temp_:113]
> 80: 025 107 113 113 # RHS_SUBS: [s:107] sub [_temp_:113] =>
> [_temp_:113]
> 84: 042 107 112 # LENGTH: [s:107] => [_temp_:112]
> 87: 025 107 112 112 # RHS_SUBS: [s:107] sub [_temp_:112] =>
> [_temp_:112]
> 91: 042 112 112 # LENGTH: [_temp_:112] => [_temp_:112]
> 94: 092 113 112 113 # RHS_SUBS_CHECK: [_temp_:113] sub [_temp_:112]
> # => [_temp_:113]
> 98: 036 111 113 # QPRINT: [_temp_:113]
>
> Three lengths, and three RHS subscripts. A 40% less efficient solution.
> We could help things out by precalculating length(s):
> }}}
<eucode>
> integer len
> len = length(s)
> ? s[len][length(s[len])]
> <font color="#330033"></eucode>
{{{
...</font><font color="#0000FF">and
> </font><font color="#330033">get:</font>
> 103: 042 107 115 # LENGTH: [s:107] => [len:115]
> 106: 087 115 # DISPLAY_VAR: [len:115]
> 108: 058 14 # STARTLINE: 14 <<? s[len][length(s[len])]>>
> 110: 025 107 115 113 # RHS_SUBS: [s:107] sub [len:115] => [_temp_:113]
> 114: 025 107 115 112 # RHS_SUBS: [s:107] sub [len:115] => [_temp_:112]
> 118: 042 112 112 # LENGTH: [_temp_:112] => [_temp_:112]
> 121: 092 113 112 113 # RHS_SUBS_CHECK: [_temp_:113] sub [_temp_:112]
> # => [_temp_:113]
> 125: 036 111 113 # QPRINT: [_temp_:113]
>
> Two lengths and three RHS subscripts (the DISPLAY_VAR and STARTLINE are
> artifacts of "with trace," so they can be ignored for this discussion).
> That's only a 20% loss of efficiency. Ah, but what if we do:
> }}}
<eucode>
> sequence slen
> slen = s[len]
> ? slen[length(slen)]
> <font color="#330033"></eucode>
{{{
...now we get:</font>
> 103: 042 107 115 # LENGTH: [s:107] => [len:115]
> 128: 058 17 # STARTLINE: 17 <<slen = s[len]>>
> 130: 025 107 115 116 # RHS_SUBS: [s:107] sub [len:115] => [slen:116]
> 134: 097 116 # SEQUENCE_CHECK: [slen:116]
> 140: 042 116 113 # LENGTH: [slen:116] => [_temp_:113]
> 143: 025 116 113 113 # RHS_SUBS: [slen:116] sub [_temp_:113] =>
> # [_temp_:113]
> 147: 036 111 113 # QPRINT: [_temp_:113]
>
> We got rid of the subscript, but added a sequence type check. That's
> probably less expensive than a subscript, so it probably saved some,
> but it's still more expensive than using $'s.
>
> So the end result is that for writing more complicated code, you've made
> the code less efficient than it could be. I think the libary should be
> coded to the current version of Euphoria, which is currently 2.5.
> Especially for the $, since it does offer a bit more than syntactic
> sugar.
>
> Matt Lewis
>
Yea and also because of crash_routine() {Error handling?}. I'm sure most of the
people who are still using v2.4, are using it because v2.5 parses the whole file
and any includes before execution + the the fact that the frontend was translated
to C from Euphoria. But execution speed in v2.5 is the fastest yet. I'm guessing
Rob will do even more optimizations, and loading & execution speed will become
slighty faster in v3.0. Afterall, he rather do bug fixes and optimzations rather
than give us new features 
.
Regards,
Vincent
----------------------------------------------
___ __________ ___
/__/\ /__________\ |\ _\
\::\'\ //::::::::::\\ |'|::|
\::\'\ //:::_::::_:::\\ |'|::|
\::\'\ //::/ |::| \::\\ |'|::|
\::\'\ //::/ |::| \::\\|'|::|
\::\'\__//::/ |::| \::\|'|::|
\::\','/::/ |::| \::\\|::|
\::\_/::/ |::| \::\|::|
\::,::/ |::| \:::::|
\___/ |__| \____|
.``.
',,'
|
Not Categorized, Please Help
|
|
