Re: More LTC timings...
From: Tom St Denis (tomstdenis_at_iahu.ca)
Date: 06/18/03
- Next message: Brian Gladman: "Re: More LTC timings..."
- Previous message: Hagen: "Re: Epimenidis"
- In reply to: Shill: "Re: More LTC timings..."
- Next in thread: Brian Gladman: "Re: More LTC timings..."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Wed, 18 Jun 2003 13:32:32 GMT
Shill wrote:
>>As you suggest, in both cases this is almost certainly the stress
>>on the processor caches - which is especially in evidence on the
>>P4 with only 8k at L1.
>
>
> Northwood's 512 KB L2 cache is only 7 cycles away...
>
> www.aceshardware.com/Spades/read.php?article_id=20000192
The Athlons 64KB L1 [data] is only 2 and the L2 [iirc] is 20.
For all of the ciphers the tables are less than 64KB so after the first
couple thousand operations the entire thing is in the cache.
One downside to the "randomized" approach is you have to run it for much
longer to get realistic results. For example, when testing encryption
with randomized plaintexts the first thousand blocks will skew the
results since the tables will not be in the cache yet. So even if the
processor can cache it you still get many misses right away.
The non-randomized approach is more of an ideal. E.g. if everything was
in the cache this is what you would aim for.
Tom
- Next message: Brian Gladman: "Re: More LTC timings..."
- Previous message: Hagen: "Re: Epimenidis"
- In reply to: Shill: "Re: More LTC timings..."
- Next in thread: Brian Gladman: "Re: More LTC timings..."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|