Received: by 10.224.70.194 with SMTP id e2mr590840qaj.4.1350295323414;
        Mon, 15 Oct 2012 03:02:03 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.236.115.33 with SMTP id d21mr1350475yhh.12.1350295323387; Mon,
 15 Oct 2012 03:02:03 -0700 (PDT)
Path: r17ni24752519qap.0!nntp.google.com!l8no52359448qao.0!postnews.google.com!g4g2000yqk.googlegroups.com!not-for-mail
Newsgroups: comp.lang.forth
Date: Mon, 15 Oct 2012 03:02:03 -0700 (PDT)
Complaints-To: groups-abuse@google.com
Injection-Info: g4g2000yqk.googlegroups.com; posting-host=144.177.35.1; posting-account=W9Y9TgoAAAAe3pS80Z-tHCcq6DoIqBGn
NNTP-Posting-Host: 144.177.35.1
References: <6bef0964-011f-4020-9d31-f7c887a52946@googlegroups.com>
 <4626464.gGs9T4UXBT@sunwukong.fritz.box> <k5c91a$otl$3@dont-email.me>
 <51932083.Wq75TzlriR@sunwukong.fritz.box> <k5cjvu$tru$1@dont-email.me>
 <15345671.vjEroXH6uk@sunwukong.fritz.box> <2012Oct15.112840@mips.complang.tuwien.ac.at>
User-Agent: G2/1.0
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)
Message-ID: <d56f0bc4-3cfd-437a-a7d9-59733526b035@g4g2000yqk.googlegroups.com>
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
Content-Transfer-Encoding: quoted-printable

On Oct 15, 10:56=A0am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
wrote:
> 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
> <http://www.complang.tuwien.ac.at/anton/memory-wall.html>.
>
> 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?