phc-discussions - Re: [PHC] babbling about trends

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 linux-cve-announce 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.