[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <18010620179.20140403223036@gmail.com>
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