22 Jul
2016
22 Jul
'16
5:02 a.m.
On Jul 21, 2016, at 8:55 PM, ben <bfranchuk at
jetnet.ab.ca> wrote:
On 7/21/2016 9:34 PM, Guy Sotomayor Jr wrote:
A read and cuss item I see. Thank you, but it seems it is still big $$$
for good compiler to follow the ever changing rules.
And yet they do. Processors are getting more and more complex in order
to deliver power/performance improvements. Larger caches with more ways,
deeper/wider pipes, more execution slots, number of rename registers, etc.
What do you expect? TNSTAAFL if you want to extract every last cycle of
performance out of a particular uArch. The good news is that most of the
time the uArch improvements work reasonably well with relatively non-specific
optimizations.
TTFN - Guy
On Jul 21, 2016, at 6:53 PM, ben <bfranchuk at
jetnet.ab.ca> wrote:
On 7/20/2016 10:42 AM, Pete Turnbull wrote:
You read the Intel Optimization Guide.
http://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32…
TTFN - Guy On 20/07/2016 16:44, Paul Koning wrote:
> It is true that a few RISC architectures are not very scrutable.
> Itanium is a notorious example, as are some VLIW machines. But many
> RISC machines are much more sane. MIPS and ARM certainly are no
> problem for any competent assembly language programmer.
Indeed. I've written a modest amount of assembly language code for
MIPS, and a bit more for ARM, and I didn't find either at all
inscrutable. Yes, be aware of pipelining and branches and so on, but
it's not hard.
But alas , they seem to change cache and pipeline with every cpu
starting with 386. How can one write effective programs for large
data memory access, with out this knowledge?