Message from discussion The "memory wall" (was: mr paysan ...)
Received: by 10.224.70.194 with SMTP id e2mr590840qaj.4.1350295323414;
Mon, 15 Oct 2012 03:02:03 -0700 (PDT)
Received: by 10.236.115.33 with SMTP id d21mr1350475yhh.12.1350295323387; Mon,
15 Oct 2012 03:02:03 -0700 (PDT)
Date: Mon, 15 Oct 2012 03:02:03 -0700 (PDT)
Injection-Info: g4g2000yqk.googlegroups.com; posting-host=18.104.22.168; posting-account=W9Y9TgoAAAAe3pS80Z-tHCcq6DoIqBGn
X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64;
Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR
3.0.30729; Media Center PC 6.0; InfoPath.3; .NET4.0C; .NET4.0E; MS-RTC LM 8; ),gzip(gfe)
Subject: Re: The "memory wall" (was: mr paysan ...)
From: Mark Wills <forthfr...@gmail.com>
Injection-Date: Mon, 15 Oct 2012 10:02:03 +0000
Content-Type: text/plain; charset=ISO-8859-1
On Oct 15, 10:56=A0am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
> Bernd Paysan <bernd.pay...@gmx.de> writes:
> >The memory wall is
> >not something I made up.
> No, it's something that William Wulf and Sally McKee made up. =A0And
> their technical arguments were wrong, and I debunked them in
> The general idea that there are programs where memory latency is the
> main contributor to run-time is not wrong. =A0It seems to me that, for
> general-purpose CPUs, the proportion of such programs is getting
> smaller these days, because the relative speed of CPUs and memory
> stays the same, but caches become bigger over time.
> Another idea, which was not meant at all by the Wulf&McKee paper is
> that there are memory-bandwidth-limited programs, where a large
> proportion of the run-time is spent transferring data between the CPU
> and memory. =A0The proportion of such programs may be rising, because
> CPUs gain more cores (slowly), wider SIMD units, and (GP)GPUs, and
> that seems to eat bandwidth faster than the bandwidth grows from
> having faster and wider memory interfaces.
> In any case, there are a lot of programs that are CPU-bound, and for
> those a faster CPU is helpful.
> - anton
> M. Anton Ertl =A0http://www.complang.tuwien.ac.at/anton/home.html
> comp.lang.forth FAQs:http://www.complang.tuwien.ac.at/forth/faq/toc.html
> =A0 =A0 =A0New standard:http://www.forth200x.org/forth200x.html
> =A0 =A0EuroForth 2012:http://www.euroforth.org/ef12/
If a cache is not a solution for slow memory, then what is it?