Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Thomas Koenig <tkoenig@netcologne.de>
Newsgroups: comp.arch
Subject: Re: architectural goals, Byte Addressability And Beyond
Date: Sat, 1 Jun 2024 08:50:22 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 36
Message-ID: <v3ence$2mqqp$1@dont-email.me>
References: <v0s17o$2okf4$2@dont-email.me> <v36bva$10k3v$2@dont-email.me>
 <2024May29.090435@mips.complang.tuwien.ac.at>
 <v38opv$1gsj2$3@dont-email.me> <v38riq$1aqo$1@gal.iecc.com>
 <2024May30.142717@mips.complang.tuwien.ac.at>
 <v39vn6$1n8gd$1@dont-email.me> <v3cfg9$27l4d$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 01 Jun 2024 10:50:22 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="6cdf7fda84200093ba41720f0ddfb924";
	logging-data="2845529"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/vWnzmkzireboebPMZ7VLOq9POtjPF4KM="
User-Agent: slrn/1.0.3 (Linux)
Cancel-Lock: sha1:H/nuoACTiUdI58NXNmjqhyj0lKI=
Bytes: 2806

Terje Mathisen <terje.mathisen@tmsw.no> schrieb:
> Thomas Koenig wrote:
>> Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
>> 
>>> It's still marketing.  I have listened to several talks about
>>> converting S/360 programs to C code that can be run on arbitrary
>>> hardware, and IBM's audience hears about such things, too, so IBM's
>>> sales force has to provide reasons for not jumping ship.  And all
>>> these new features that sound like they are useful are such reasons.
>>> Things like decimal FP and CU14.
>>>
>>> The fact that these feature provide no actual benefit is their best
>>> property:
>> 
>> No actual benefit?
>> 
>> If you make such a strong statement, I assume that you have done a
>> thorough analysis of this feature for typical mainframe workloads
>> and can support your claims with benchmarks.
>> 
>> Care to show exactly what you did, and what the results were?
>> 
> I am pretty sure Anton is correct, at least for data residing in RAM, 
> since any reasonably efficient sw algorithm to do the same thing should 
> be able to keep up with memory bandwidth, right?

I'm not sure that would be the case for text containing some
non-ASCII characters, where you cannot predict branches well
(consider Å, Ø and Æ, which together appear to make up around
a bit more than 2.5% according to a random statistic I just
grabbed off the Internet), or ä, ö and ü which have around 1.5%
occurrence together.

In Chinese or Japanese text, I assume the spaces and punctuation
are 7-bit ASCII (are they, actually?) so things would be even
worse for branch prediction.