1. RE: Type-checking performance
- Posted by Chris Bensler <bensler at nt.net> Feb 01, 2005
- 440 views
- 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
- 423 views
- 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
- 396 views
- 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
- Posted by Robert Craig <rds at RapidEuphoria.com> Feb 02, 2005
- 437 views
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