Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.arch
Subject: Re: Retirement hobby (was Re: 80286 protected mode)
Date: Wed, 23 Oct 2024 07:25:42 -0700
Organization: A noiseless patient Spider
Lines: 57
Message-ID: <86sesmvqu1.fsf@linuxsc.com>
References: <2024Oct6.150415@mips.complang.tuwien.ac.at> <memo.20241006163428.19028W@jgd.cix.co.uk> <2024Oct7.093314@mips.complang.tuwien.ac.at> <7c8e5c75ce0f1e7c95ec3ae4bdbc9249@www.novabbs.org> <2024Oct8.092821@mips.complang.tuwien.ac.at> <ve5ek3$2jamt$1@dont-email.me> <be506ccef76d682d13205c69c761a086@www.novabbs.org> <ve6oiq$2pag3$1@dont-email.me> <ve6tv7$2q6d5$1@dont-email.me> <86y12uy8ku.fsf@linuxsc.com> <jwv34kx5afd.fsf-monnier+comp.arch@gnu.org> <venpin$241bk$2@dont-email.me> <veu2uv$3cluq$1@dont-email.me> <veudt1$3ep62$1@dont-email.me> <vf3qgi$ijah$1@dont-email.me> <vf4u1t$qo5f$2@dont-email.me> <vf4ve7$rtqt$1@dont-email.me> <86zfmwvs5w.fsf@linuxsc.com> <vf7gk0$1ce7n$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Wed, 23 Oct 2024 16:25:43 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="17b06a4b9730bb653a99f1c75aa1d263";
	logging-data="2176485"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19zrvBq03iRuH5f+tZfUsE7MeS27Ch/j6g="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:hcFexCvVBGbPqf16Vh2yjN+FFdo=
	sha1:kAmyWw2uC+ZYBTJi1fB7IuY5JVU=
Bytes: 4027

Terje Mathisen <terje.mathisen@tmsw.no> writes:

> Tim Rentsch wrote:
>
>> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>>
>> [C vs assembly]
>>
>>> For near-light-speed code I used to write it first in C, optimize
>>> that, then I would translate it into (inline) asm and re-optimize
>>> based on having the full cpu architecture available, before in the
>>> final stage I would use the asm experience to tweak the C just
>>> enough to let the compiler generate machine code quite close
>>> (90+%) to my best asm, while still being portable to any cpu with
>>> more or less the same capabilities.
>>>
>>> One example:  When I won an international competition to write the
>>> fastest Pentomino solver (capable of finding all 2339/1010/368/2
>>> solutions of the 6x10/5x12/4x15/3x20 layouts), I also included the
>>> portable C version.
>>>
>>> My asm submission was twice as fast as anyone else, while the C
>>> version was still fast enough that a couple of years later I got a
>>> prize in the mail:  Someone in France had submitted my C code,
>>> with my name & address, to a similar competition there and it was
>>> still faster than anyone else. :-)
>>
>> I hope you will consider writing a book, "Writing Fast Code" (or
>> something along those lines).  The core of the book could be, oh,
>> let's say between 8 and 12 case studies, starting with a problem
>> statement and tracing through the process that you followed, or
>> would follow, with stops along the way showing the code at each
>> of the different stages.
>>
>> If you do write such a book I guarantee I will want to buy one.
>
> Thank you Tim!

I know from past experience you are good at this.  I would love
to hear what you have to say.

> Probably not a book but I would consider writing a series of blog
> posts similar to that, now that I am about to retire:

You could try writing one blog post a month on the subject.  By
this time next year you will have plenty of material and be well
on your way to putting a book together.  (First drafts are always
the hardest part...)

> My wife and I will both go on "permanent vacation" starting a week
> before Christmas. :-)

I'm guessing that permanent vacation will be some mixture of actual
vacation and self-chosen "work".  In any case I hope you both enjoy
the time.

P.S. Is the email address in your message a good way to reach you?