🚀 go-pugleaf

In article <1994Apr8.185204.20310@nmt.edu> swhitlat@nmt.edu (Steven Whitlatch) writes:
>
>	Perhaps the confusion about what cache we are taliking
>	about is my fault, seems to be. I apologize.
>
>	It is the "optional turbo cache module," as from my Zeos manual.
>	It is commonly refered to as the "external cpu cache," as opposed
>	to the internal 8K cpu cache, and comes in numbers such as
>	256K, 128K, and some machines use 64K.
>
>	I think I've seen 3 respones as to my question about what
>	speed increase could be expected by using the cache:
>
>		a) %10	
>		b) not telling (the zeos guy)
>		c) %80
>
>	The reason I'm so interested in the performance increase
>	is because I am using a hacked XFree_2.0 mono sever in Linux.
>	The problem is that although XFree is generally a fast X-Server,
>	XFree does not support the Viper, due to Diamond's policies.
>	So, some of us Viper users have hacked the mono server to get
>	it to work.  But it is not very fast.
>
>	I thought I might throw a cache at the problem.   And if the
>	performance increase is in fact going to be %80, then it might
>	be worth the trouble.  But, slow+(.10*slow)=(still slow).  And
>	that's not worth the $200 price.
>
	Two thoughts:
	1) Throwing hardware at a problem generally is not a great
solution.
	2) A, B, C are all true.  A) 10% is typical.  C) 80% is
true if you are using a CPU intensive application.  For example,
if your core code and data is 128K or less, it will all fit into
a L2 128K cache and be MUCH speedier than if you didn't have
the cahce.  On the other hand, if your program is often accessing
data outside of the cache, your hit rate goes down and you won't
see as much of an improvement.

	The way I looked at is the 10% cost less than 10% of
my system.  So for less than 10% more in cost, I got essentially
a 10% faster machine.

	I would hazard a guess that you won't see a 80% improvement
in speed on the video driver since A) it's probably larger
than 256K, and the data it access certianly is, and B) With
the rest of Linux running, it won't all fit into the cache
anyway.  But I could be wrong.  You could try to profile the
code and see wht happens.

>	
>
>	Thanks,
>
>	Steve Whitlatch
>	swhitlat@prism.nmt.edu


--
--
Greg d. Moore           | All that glitters is not gold.
Green Mountain Software |
Troy NY, 12180          | (Also strider@acm.rpi.edu)