lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 3 Apr 2014 22:30:36 +0200
From: Krisztián Pintér <pinterkr@...il.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] babbling about trends


Thomas Pornin (at Thursday, April 3, 2014, 9:52:15 PM):

> Roughly speaking, cache is (usually) SRAM, which main RAM is
> (usually) DRAM. ...

thanks for the detailed exposition. i really appreciate it.

> Amount of
> SRAM available to a given CPU has remained mostly constant over the
> years.

on the other hand, i heard the argument that this is not due to the
possibilities, but rather because as you increase the size of the
cache, searching it becomes slow. this means that for non-cache uses,
it might be suitable.

if i let my mind run amok, i can imagine a CPU with no automatic
cache, but rather, manual management of different RAMs. it eliminates
the need for finding stuff in cache, the program simply decides what's
where.

> That's the core idea for RISC CPU; but it did not really win in the end

we are not at the end. in the 90's, every code generated by the
compiler was hand optimized, manually designed. obviously, if you have
more advanced building blocks, you are happy.

but the trend is, afaik, that advanced compilers have an actual model
of the CPU, and they run simulations of different code versions, using
trial and error, to find the fastest one.

this approach can be only hindered by complex CPUs that do stuff
automatically. but can be greatly aided by direct access to the
underlying machinery.

Powered by blists - more mailing lists