Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Terje Mathisen <terje.mathisen@tmsw.no>
Newsgroups: comp.arch
Subject: Retirement hobby (was Re: 80286 protected mode)
Date: Tue, 22 Oct 2024 08:27:12 +0200
Organization: A noiseless patient Spider
Lines: 53
Message-ID: <vf7gk0$1ce7n$1@dont-email.me>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 22 Oct 2024 08:27:12 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="355e1c1354e9b4b6de00c4cd67b0b4d7";
	logging-data="1456375"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18heC63X8zSY27Wj0IKUfu4WYcAssR6HO9ADtfwPlSaIw=="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Firefox/91.0 SeaMonkey/2.53.19
Cancel-Lock: sha1:1a/GyvHYpUpOuVhPqFFK+5gL89g=
In-Reply-To: <86zfmwvs5w.fsf@linuxsc.com>
Bytes: 3962

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 I book I guarantee I will want to buy one.
> 
Thank you Tim!

Probably not a book but I would consider writing a series of blog posts 
similar to that, now that I am about to retire: My wife and I will both 
go on "permanent vacation" starting a week before Christmas. :-)

I already know that this will give me more time to work on digital 
mapping projects (ref my https://mapant.no/ Norwegian topo map generated 
from ~50 TB of LiDAR), but if there's an interest in optimization I 
might do that as well.

BTW, I am also open to doing some consulting work, if the problems are 
interesting enough. :-)

Regards,
Terje

-- 
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"