From: Peter Jeremy <peter@rulingia.com>
To: Larry McVoy <lm@mcvoy.com>
Cc: tuhs@minnie.tuhs.org
Subject: Re: [TUHS] SPARC is CRAPS spelled backwards.
Date: Wed, 26 Sep 2018 05:48:17 +1000 [thread overview]
Message-ID: <20180925194817.GB29897@server.rulingia.com> (raw)
In-Reply-To: <20180925150152.GJ10989@mcvoy.com>
[-- Attachment #1: Type: text/plain, Size: 1304 bytes --]
On 2018-Sep-25 08:01:52 -0700, Larry McVoy <lm@mcvoy.com> wrote:
>On Tue, Sep 25, 2018 at 11:00:37AM +0100, Tony Finch wrote:
>> Peter Jeremy <peter@rulingia.com> wrote:
>>
>> > In the specific case of x86, I would dispute that. The various warts in
>> > the x86 instruction set and "architecture" mean that x86 code density is
>> > relatively low and on a par with SPARC code.
>>
>> This paper has a nice survey of instruction set densities, which very much
>> disagrees with your statement:
>>
>> http://web.eece.maine.edu/~vweaver/papers/iccd09/iccd09_density.pdf
>
>That's a neat paper, I like it, thanks for the pointer. I'm curious
>why Peter thought what he thought, my guess would have been more like
>what the paper showed, but that was a "hand optimized assembly", maybe
>the compilers aren't that good? I dunno, Peter, care to comment?
I agree that looks like an interesting paper - I've skimmed it and
will have to read it in details. I was thinking back to when I was
using a mixture of SPARC and x86 at a previous job. I didn't do any
careful analysis, more eyeballing various executables and gut feeling.
I no longer have access to that environment. In view of that paper,
I'll withdraw my claim since it's not backed up by evidence.
--
Peter Jeremy
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 963 bytes --]
next prev parent reply other threads:[~2018-09-25 19:49 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.98.1535822297.3725.tuhs@minnie.tuhs.org>
2018-09-23 18:37 ` Don Hopkins
2018-09-23 19:49 ` A. P. Garcia
2018-09-23 21:17 ` Paul Winalski
2018-09-24 11:25 ` Tony Finch
2018-09-24 19:46 ` Peter Jeremy
2018-09-24 20:20 ` Paul Winalski
2018-09-24 20:45 ` Arthur Krewat
2018-09-26 6:20 ` Peter Jeremy
2018-09-26 6:46 ` Lars Brinkhoff
2018-09-26 15:03 ` Theodore Y. Ts'o
2018-09-26 15:32 ` Paul Winalski
2018-09-26 15:44 ` Henry Bent
[not found] ` <ceae72ff-ca8b-4cc1-9666-82253c1e1683.maildroid@localhost>
2018-09-26 16:02 ` [TUHS] Fwd: " William Pechter
2018-09-26 18:24 ` [TUHS] " Donald ODona
2018-09-25 10:00 ` Tony Finch
2018-09-25 15:01 ` Larry McVoy
2018-09-25 19:48 ` Peter Jeremy [this message]
2018-09-25 18:34 ` Paul Winalski
2018-09-24 11:48 Noel Chiappa
2018-09-25 12:12 Noel Chiappa
2018-09-25 14:49 ` Theodore Y. Ts'o
2018-09-26 19:31 ` Derek Fawcus
2018-09-25 15:29 ` Arthur Krewat
2018-09-25 18:41 Noel Chiappa
2018-09-27 7:35 Paul Ruizendaal
2018-09-27 7:52 ` Arrigo Triulzi
2018-09-27 18:03 Nelson H. F. Beebe
2018-09-27 19:34 ` Nemo
2018-09-27 20:30 ` Dan Cross
2018-09-27 20:51 ` Cág
2018-09-27 21:01 ` Henry Bent
2018-09-27 21:04 ` Cág
2018-09-27 21:07 Norman Wilson
2018-09-28 12:08 Nelson H. F. Beebe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180925194817.GB29897@server.rulingia.com \
--to=peter@rulingia.com \
--cc=lm@mcvoy.com \
--cc=tuhs@minnie.tuhs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).