Re: xorg +XGI Volari XP5

["Thomas E. Spanjaard" <tgen@xxxxxxxxxxxxx>]

r.dragonflybsd.org> <426e9cc1$0$719$415eb37d@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
In-Reply-To: <426e9cc1$0$719$415eb37d@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 31
Message-ID: <426eb372$0$720$415eb37d@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
NNTP-Posting-Host: 84.83.37.40
X-Trace: 1114551154 crater_reader.dragonflybsd.org 720 84.83.37.40
Xref: crater_reader.dragonflybsd.org dragonfly.users:3156

Hummel Tom wrote:
> Numbers? I think "running circles" is unlikely.

I don't have any numbers yet on the Turion64 specific, but it's just a 
Athlon64 with some adjustments so you can make pretty solid claims about 
Turion64 performance when you compare the Athlon64 with the Pentium-M.

>  <snippety snap>

The difference here is between measured thermal power dissipation when 
running a certain task (i.e. BurnK7), and maximum thermal power 
dissipation. First, I measured total CPU power usage. Second, a task 
like BurnK7 never stresses the CPU to it's fullest. A large part of the 
CPU die consists of cache (L1, L2) which gets little to do when running 
a synthetic 'benchmark' like BurnK7. With intensive cache invalidation 
and reloading action, a lot of energy is consumed, and logically a lot 
of heat generated. Third, of course you can't ever get the caches to 
update completely every clock cycle, due to memory slowness and the 
serial nature of cache invalidation in current x86 (and other?) CPU 
designs (which results in cache invalidation taking a lot of CPU cycles).

However, in this field politics are concerned as well. There is truth in 
your words about differing policies on TDP values for both AMD and 
Intel, but you look the wrong way. AMD actually specifies a true real 
maximum TDP, whereas Intel specifies an average maximum TDP based on 
stresstests. However, this doesn't mean AMD rates it's TDP too high, but 
rather Intel too low.

Cheers,
		-- Thomas E. Spanjaard
		   tgen@xxxxxxxxxxxxx