Re: (Almost) Rock-n-Roll - "The Bunny Hop" (1953)

Liste des GroupesRevenir à col misc 
Sujet : Re: (Almost) Rock-n-Roll - "The Bunny Hop" (1953)
De : invalid (at) *nospam* invalid.invalid (Richard Kettlewell)
Groupes : comp.os.linux.misc
Date : 10. Jan 2025, 10:10:16
Autres entêtes
Organisation : terraraq NNTP server
Message-ID : <wwvy0zj11c7.fsf@LkoBDZeT.terraraq.uk>
References : 1 2 3 4 5 6
User-Agent : Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)
The Natural Philosopher <tnp@invalid.invalid> writes:
On 10/01/2025 07:58, 186282@ud0s4.net wrote:
On 1/10/25 2:11 AM, The Natural Philosopher wrote:
I don't think so. About the only thing that is proximity sensitive
is cacheing. That is you want to try and ensure that you are
operating out of cache, but the algorithms for what part of the
instructions are cached and what are not is beyond my ability to
identify, let alone code in...

The easy win is alignment, which allows more efficient use of memory
resources. e.g. if a function is 50 bytes long and your cache line size
is 64 bytes, you can ensure your function fits into a single cache line
by aligning its start address to a multiple of 64. It doesn’t
necessarily make that particular function faster, but it leaves more
room in the cache for everything else - so more cache hits in the
program as a whole. The same idea applies at other levels of the memory
hierarchy, e.g. the system page size (usually, but not always,
4Kbyte). Compilers and linkers already exploit all this quite
effectively.

The harder strategy is to put group data (or code) according to how it’s
used. If a function is going to operate on several different values then
having them adjacent in memory maximises the chances they’ll be read (or
cached) in a single operation. Main memory access can be very slow
(hundreds of times the latency of individual instructions) so getting
this right can have substantial benefits. Easy enough for a little
struct but more challenging for a complex data structure.

So we don't have to. I used to do *86 assembler, but what todays C
compilers spit out is better than any hand crafted assembler is.
>
My mathematical friend only uses assembler to access some weird
features of a specific intel architecture to do with vector
arithmetic. He writes C library functions in assembler to access them.
>
Because the compilers don't acknowledge their existence - yet.

I’ve had good results using GCC’s native support for vector operations,
though better on x86 than Arm so far, but my needs aren’t complex.

The context where I’ve had to use a lot of assembler is achieving
constant-time operation. Compilers love conditional branches...
(Actually vector instructions are better for this, but not all of my
code is vectorizable.)

--
https://www.greenend.org.uk/rjk/

Date Sujet#  Auteur
9 Jan 25 * (Almost) Rock-n-Roll - "The Bunny Hop" (1953)8186282@ud0s4.net
9 Jan 25 `* Re: (Almost) Rock-n-Roll - "The Bunny Hop" (1953)7Allodoxaphobia
9 Jan 25  +- Re: (Almost) Rock-n-Roll - "The Bunny Hop" (1953)1John Ames
10 Jan 25  `* Re: (Almost) Rock-n-Roll - "The Bunny Hop" (1953)5186282@ud0s4.net
10 Jan 25   `* Re: (Almost) Rock-n-Roll - "The Bunny Hop" (1953)4The Natural Philosopher
10 Jan 25    `* Re: (Almost) Rock-n-Roll - "The Bunny Hop" (1953)3186282@ud0s4.net
10 Jan 25     `* Re: (Almost) Rock-n-Roll - "The Bunny Hop" (1953)2The Natural Philosopher
10 Jan 25      `- Re: (Almost) Rock-n-Roll - "The Bunny Hop" (1953)1Richard Kettlewell

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal