1. RE: Type-checking performance
- Posted by Chris Bensler <bensler at nt.net>
Feb 01, 2005
-
Last edited Feb 02, 2005
Patrick Barnes wrote:
>
>
> Can you explain why this:
> }}}
<eucode>
> constant ITER = 10000000
> atom time_elapsed
>
> type type1(object x)
> return 1
> end type
>
> type type2(integer x)
> return 1
> end type
>
> type type3(object x)
> if integer(x) then
> return 1
> end if
> end type
>
> --type4 is integer
>
> type1 var1 var1 = 0
> type2 var2 var2 = 0
> type3 var3 var3 = 0
> integer var4 var4 = 0
>
> time_elapsed = time()
> for a = 1 to ITER do var1 += 1 end for
> printf(1, "Type1: %f\n", { time() - time_elapsed } )
>
> time_elapsed = time()
> for a = 1 to ITER do var2 += 1 end for
> printf(1, "Type2: %f\n", { time() - time_elapsed } )
>
> time_elapsed = time()
> for a = 1 to ITER do var1 += 1 end for
> printf(1, "Type3: %f\n", { time() - time_elapsed } )
>
> time_elapsed = time()
> for a = 1 to ITER do var4 += 1 end for
> printf(1, "Type4: %f\n", { time() - time_elapsed } )
> }}}
<eucode>
>
> Outputs this:
> Type1: 0.820000
> Type2: 0.950000
> Type3: 0.830000
> Type4: 0.060000
>
> Rob, I thought you said you optimised the case where a type returns 1
> immediately?
> The other odd thing here is that Type3 is faster than Type2, even
> though it actually does some computation inside the type.
>
> What's going on internally?
>
> --
> MrTrick
>
type3 is incorrect. It doesn't account for cases that are not integers.
I would have expected eu to tell you that you have an ambiguous return
from type3.
to be correct, it should be..
type type3(object x)
if integer(x) then
return 1
else
return 0
end if
end type
... or ...
type type3(object x)
return integer(x)
end type
types will always be slower, since they are routine calls.
I don't know about the optimization thing, but I don't see the point of
creating a type if it will always return 1 (ok, you could clone the
object type, for I dunno why). And if for some reason I did need it, I
don't know that I would want Eu to optimize it away. I likely have it
there for a reason, such as for creating a routine id.
IMO, type2 is incorrect also. If it is passed a variable that is not an
integer, eu will bail, and report the typecheck error immediately,
amidst processing the type itself, rather than returning a boolean to
the callee.
The proper way would be to declare the argument as an object and test
for the type of the variable from within the type function. Such as your
example type3.
Chris Bensler
Code is Alchemy
2. RE: Type-checking performance
- Posted by Chris Bensler <bensler at nt.net>
Feb 01, 2005
-
Last edited Feb 02, 2005
Patrick Barnes wrote:
>
>
> Heh... oops.
> > }}}
<eucode>
> ...
> > time_elapsed = time()
> > for a = 1 to ITER do var1 += 1 end for
> > printf(1, "Type1: %f\n", { time() - time_elapsed } )
> >
> > time_elapsed = time()
> > for a = 1 to ITER do var2 += 1 end for
> > printf(1, "Type2: %f\n", { time() - time_elapsed } )
> >
> > time_elapsed = time()
> > for a = 1 to ITER do var1 += 1 end for
> > printf(1, "Type3: %f\n", { time() - time_elapsed } )
> This should actually be 'var3 +=1'
> >
> > time_elapsed = time()
> > for a = 1 to ITER do var4 += 1 end for
> > printf(1, "Type4: %f\n", { time() - time_elapsed } )
> > </eucode>
{{{
> >
> > Outputs this:
> > Type1: 0.820000
> > Type2: 0.950000
> > Type3: 0.830000
> > Type4: 0.060000
> Now outputs this:
> Type1: 0.890000
> Type2: 0.910000
> Type3: 0.860000
> Type4: 0.060000
>
> > The other odd thing here is that Type3 is faster than Type2, even
> > though it actually does some computation inside the type.
>
> Now, type3 even beats type1... what's going on?
>
> --
> MrTrick
>
Try rearranging your code. I suspect the time discrepency between the
first 3 is simply to do cpu load.
Try running type3, type1, type2.
Chris Bensler
Code is Alchemy
3. RE: Type-checking performance
- Posted by Pete E <euphoria at eberlein.org>
Feb 01, 2005
-
Last edited Feb 02, 2005
Patrick Barnes wrote:
>
> Now, type3 even beats type1... what's going on?
>
> --
> MrTrick
Not on Linux (w/ ITER*=10):
Eu 2.5:
Type1: 9.740000
Type2: 8.860000
Type3: 9.810000
Type4: 0.630000
Eu 2.4:
Type1: 6.720000
Type2: 5.110000
Type3: 5.350000
Type4: 0.620000
Strikes me as odd that 2.4 is that much faster.
Pete E.
4. RE: Type-checking performance
Pete E wrote:
> Patrick Barnes wrote:
> >
> > Now, type3 even beats type1... what's going on?
> >
> > --
> > MrTrick
>
> Not on Linux (w/ ITER*=10):
>
> Eu 2.5:
> Type1: 9.740000
> Type2: 8.860000
> Type3: 9.810000
> Type4: 0.630000
>
> Eu 2.4:
> Type1: 6.720000
> Type2: 5.110000
> Type3: 5.350000
> Type4: 0.620000
>
> Strikes me as odd that 2.4 is that much faster.
Using 2.5 beta vs 2.4 on DOS or Windows, I find 2.4 to be
significantly faster on this, by about the same ratio as you
show above, *but* using my latest build of 2.5,
I find 2.5 to be a bit faster than 2.4. I don't know why,
but modern CPU's are very complex, and small differences
in the machine code stream can sometimes make a big difference in time.
I don't recall tweaking anything to do with types or calls in 2.5,
certainly not since 2.5 beta came out.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
