1. Type-checking performance
- Posted by Patrick Barnes <mrtrick at gmail.com> Feb 01, 2005
- 462 views
- Last edited Feb 02, 2005
Can you explain why this:
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 } ) }}}
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 }}}2. Re: Type-checking performance
- Posted by Patrick Barnes <mrtrick at gmail.com> Feb 01, 2005
- 456 views
- Last edited Feb 02, 2005
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
3. Re: Type-checking performance
- Posted by Patrick Barnes <mrtrick at gmail.com> Feb 01, 2005
- 452 views
- Last edited Feb 02, 2005
> 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. Oops, I fixed that now, no change in timings. > 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. Cloning the object type, that's why. And I do have a very good reason for wanting to do it, but it would be less beneficial if it wasn't optimised. > 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. Yes, I'm aware of that. This is just a test harness, and surprisingly type2 was the slowest of the bunch. -- MrTrick
4. Re: Type-checking performance
- Posted by Patrick Barnes <mrtrick at gmail.com> Feb 01, 2005
- 438 views
- Last edited Feb 02, 2005
> Try rearranging your code. I suspect the time discrepency between the > first 3 is simply to do cpu load. > Try running type3, type1, type2. I rearranged them in all sorts of permutations, it didn't make more than 0.01 difference. -- MrTrick
5. Re: Type-checking performance
- Posted by Patrick Barnes <mrtrick at gmail.com> Feb 01, 2005
- 493 views
- Last edited Feb 02, 2005
> 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. Uh yes, I'm running this on 2.4, using exw. -- MrTrick ------------------------------------------------------------------------------------- Catapultum habeo. Nisi pecuniam omnem mihi dabis, ad caput tuum saxum immane mittam
6. Re: Type-checking performance
- Posted by Patrick Barnes <mrtrick at gmail.com> Feb 02, 2005
- 454 views
On Tue, 01 Feb 2005 18:20:14 -0800, Robert Craig <guest at rapideuphoria.com> wrote: > 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. What are your thoughts on optimising types that do nothing but return 1, basically alias them to the parent type? While from a technical standpoint it does nothing, from a semantic point of view it can be very helpful, as we can see what is expected in a parameter without a performance hit. -- MrTrick
7. Re: Type-checking performance
- Posted by Robert Craig <rds at RapidEuphoria.com> Feb 02, 2005
- 457 views
Patrick Barnes wrote: > What are your thoughts on optimising types that do nothing but return > 1, basically alias them to the parent type? > While from a technical standpoint it does nothing, from a semantic > point of view it can be very helpful, as we can see what is expected > in a parameter without a performance hit. I don't have any special optimization for this, and I don't see much demand for it, since you can always say "without type_check". Any optimization takes time and has the risk of introducing a bug. I need to concentrate my efforts on areas where I can make a big difference, with little risk, and it will help a lot of programs. Regards, Rob Craig Rapid Deployment Software http://www.RapidEuphoria.com
8. Re: Type-checking performance
- Posted by Patrick Barnes <mrtrick at gmail.com> Feb 02, 2005
- 459 views
> Patrick Barnes wrote: > > What are your thoughts on optimising types that do nothing but return > > 1, basically alias them to the parent type? > > While from a technical standpoint it does nothing, from a semantic > > point of view it can be very helpful, as we can see what is expected > > in a parameter without a performance hit. > > I don't have any special optimization for this, and > I don't see much demand for it, since you can always say > "without type_check". Ah, oops, I forgot about that. Suggestion withdrawn. > Any optimization takes time and has the risk of introducing a bug. > I need to concentrate my efforts on areas where I can make > a big difference, with little risk, and it will help a lot > of programs. While I applaud that sentiment, and I agree - don't worry about optimising away aliases... What about things that can make a huge difference, but carry some degree of risk, like fixing the include system to allow local and global includes? Or fixing (or maybe completely getting rid of) the broken namespace system? If you restrict yourselves only to 'low risk' improvements, then there is a very 'high risk' of causing a mutiny amongst the long-time users of Euphoria, who are responsible for most of Euphoria's libraries... -- MrTrick
9. Re: Type-checking performance
- Posted by "Kat" <gertie at visionsix.com> Feb 02, 2005
- 450 views
On 2 Feb 2005, at 14:08, Patrick Barnes wrote: <snip> > What about things that can make a huge difference, but carry some > degree of risk, like fixing the include system to allow local and > global includes? Or fixing (or maybe completely getting rid of) the > broken namespace system? > If you restrict yourselves only to 'low risk' improvements, then there > is a very 'high risk' of causing a mutiny amongst the long-time users > of Euphoria, who are responsible for most of Euphoria's libraries... We'll just switch to Bach or whatever Matt is calling his interpreter. Or OpenEu. Kat