Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: anton@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.arch
Subject: Re: architectural goals, Byte Addressability And Beyond
Date: Thu, 30 May 2024 15:04:35 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 48
Message-ID: <2024May30.170435@mips.complang.tuwien.ac.at>
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>
Injection-Date: Thu, 30 May 2024 17:27:18 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="46db1f935b2b8b941d470a80861909b8";
	logging-data="1847694"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX187s/CfjcCipHtm5hGojrFr"
Cancel-Lock: sha1:IRgXDoaLBn8Vn4fSa6neIXOYmj8=
X-newsreader: xrn 10.11
Bytes: 3340

Thomas Koenig <tkoenig@netcologne.de> writes:
>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?

It provides no actual benefit, because UTF-32 provides no actual
benefit.  In nearly all code you don't need code points.  Dealing with
data as mostly opaque strings in UTF-8 is less complicated *and* more
efficient than converting them to UTF-32, working with UTF-32 strings,
and converting back (even if the conversion was very cheap).

Of course there are API mistakes (like Python3) that lead to some
usage of UTF-32, but even on Intel and AMD CPUs where Python3 code
probably consumes more cycles than on other hardware, that usage has
not been enough to add instructions like CU14.

IBM z also has CU12 and CU21 (for converting between UTF-8 and
UTF-16), and such instructions could see some usage in environments
where UTF-16 is big, such as Java, JavaScript, and Windows, but even
in CPUs by Intel and AMD (with lots of Windows and JavaScript) and ARM
(Android, i.e., Java) this has not led to instructions for converting
between UTF-8 and UTF-16.

Concerning benchmarks, last I heard IBM forbids benchmarking z
hardware.  Until they change this, I'll assume their z hardware is
abysmally slow and any benchmarking would result in embarrassment, IBM
knows this and that's why they forbid benchmarking.

- anton
-- 
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
  Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>