1. Type-checking performance

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 }}}



		

		

		


	

		

							new topic
									     »
			 topic index
			 » view message
			 » categorize
		

	


	

		
		
2. Re: Type-checking performance

		

		



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




		

		

		


	

		

							new topic
										    »
				goto parent
			 			     »
			 topic index
			 » view message
			 » categorize
		

	


	

		
		
3. Re: Type-checking performance

		

		



> 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




		

		

		


	

		

							new topic
										    »
				goto parent
			 			     »
			 topic index
			 » view message
			 » categorize
		

	


	

		
		
4. Re: Type-checking performance

		

		



> 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




		

		

		


	

		

							new topic
										    »
				goto parent
			 			     »
			 topic index
			 » view message
			 » categorize
		

	


	

		
		
5. Re: Type-checking performance

		

		



> 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




		

		

		


	

		

							new topic
										    »
				goto parent
			 			     »
			 topic index
			 » view message
			 » categorize
		

	


	

		
		
6. Re: Type-checking performance

		

		



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




		

		

		


	

		

							new topic
										    »
				goto parent
			 			     »
			 topic index
			 » view message
			 » categorize
		

	


	

		
		
7. Re: Type-checking performance

		

		



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




		

		

		


	

		

							new topic
										    »
				goto parent
			 			     »
			 topic index
			 » view message
			 » categorize
		

	


	

		
		
8. Re: Type-checking performance

		

		



> 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




		

		

		


	

		

							new topic
										    »
				goto parent
			 			     »
			 topic index
			 » view message
			 » categorize
		

	


	

		
		
9. Re: Type-checking performance

		

		



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




		

		

		


	

		

							new topic
										    »
				goto parent
			 			     »
			 topic index
			 » view message
			 » categorize
		

	




			


		


		


			


				
Search


				

					

						

						
						
						

					

					
				


				
Quick Links

				

				
					
User menu

                                        Not signed in.
					

				
				
				
Misc Menu