Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.arch > #118224

Re: SIMD Considered Harmful

From MitchAlsup <user5857@newsgrouper.org.invalid>
Newsgroups comp.arch
Subject Re: SIMD Considered Harmful
References (1 earlier) <11920i6$29ujm$3@dont-email.me> <1790269788-5857@newsgrouper.org> <1194e2i$34hlg$8@dont-email.me> <1790296913-5857@newsgrouper.org> <1196rmj$3vvf7$3@dont-email.me>
Date 2026-09-26 00:29 +0000
Message-ID <1790382579-5857@newsgrouper.org> (permalink)

Show all headers | View raw


Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> posted:

> On Fri, 25 Sep 2026 00:41:53 GMT, MitchAlsup wrote:
> 
> > On Fri, 25 Sep 2026 00:08:50 -0000 (UTC), Lawrence D’Oliveiro wrote:
> >
> >> In the Cray docs somewhere, it said the break-even point where it
> >> is better to go through the setup of a vector instruction rather
> >> then execute individual scalar instructions for each set of
> >> operands is a vector length of just 2.
> >
> > Yes, when memory was 20-odd cycles away--but a 5 GHz machine will
> > find memory 200 cycles away, not 20. That changes the break-even
> > point (and the number of elements in a vector register).
> 
> I don’t see why it does. The CPU-memory gap applies to the fetching of
> operands and storing of results back to memory, regardless of whether
> the same operation is being done by a scalar functional unit or a
> vector one. The extra overhead of setting up a vector operation
> happens entirely in the CPU, so should not be (significantly) affected
> by memory speeds.

When memory was 20-cycles away, a 64-entry vector register could absorb
the entire latency 3 times. If memory is 200-cycles away, a 64-entry 
vector register can absorb only 1/3 of a memory latency.

Note we are talking about a core where we can send a new address to 
memory every clock, too.
 
> CPU speeds have become so high nowadays that it is often faster to
> compute a value again than it is to fetch the same previously-computed
> result from (cache) memory.
> 
> > In addition, for vectors that short (4), caches work.
> 
> They would work just as well for the same number of operands to
> scalar operations, no better and no worse.

Also note: the vectors as short as 2 are faster than scalars of length
2 point (above) is for 20-cycle scalar LDs (no caches on CRAY.) So, 
LD-ADD-ST is 24 cycles, while VLD-VADD-VST is ~27 cycles {extra vector
setup cycles}

Back to comp.arch | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

SIMD Considered Harmful MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-24 00:00 +0000
  Re: SIMD Considered Harmful Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-24 02:05 +0000
    Re: SIMD Considered Harmful MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-24 17:09 +0000
      Re: SIMD Considered Harmful Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-25 00:08 +0000
        Re: SIMD Considered Harmful MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-25 00:41 +0000
          Re: SIMD Considered Harmful Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-25 22:13 +0000
            Re: SIMD Considered Harmful MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-26 00:29 +0000
              Re: SIMD Considered Harmful anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-26 06:41 +0000
                Re: SIMD Considered Harmful MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-26 18:23 +0000
                Re: SIMD Considered Harmful BGB <cr88192@gmail.com> - 2026-09-26 14:47 -0500
                Re: SIMD Considered Harmful MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-26 21:31 +0000
                Re: SIMD Considered Harmful BGB <cr88192@gmail.com> - 2026-09-26 20:56 -0500
                Re: SIMD Considered Harmful scott@slp53.sl.home (Scott Lurndal) - 2026-09-28 15:29 +0000
                Re: SIMD Considered Harmful BGB <cr88192@gmail.com> - 2026-09-28 17:39 -0500
                Re: SIMD Considered Harmful scott@slp53.sl.home (Scott Lurndal) - 2026-09-29 00:09 +0000
                Re: SIMD Considered Harmful MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-10-13 21:40 +0000
                Re: SIMD Considered Harmful Torbjorn Lindgren <tl@none.invalid> - 2026-09-29 17:01 +0000
                Re: SIMD Considered Harmful BGB <cr88192@gmail.com> - 2026-09-29 20:49 -0500
    Re: SIMD Considered Harmful BGB <cr88192@gmail.com> - 2026-09-24 15:04 -0500
  Re: SIMD Considered Harmful Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-09-24 07:54 -0700
    Re: SIMD Considered Harmful MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-24 19:48 +0000
      Re: SIMD Considered Harmful Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-09-24 13:58 -0700
        Re: SIMD Considered Harmful MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-24 22:24 +0000
          Re: SIMD Considered Harmful MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-25 00:27 +0000
          Re: SIMD Considered Harmful EricP <ThatWouldBeTelling@thevillage.com> - 2026-09-25 17:44 -0400
            Re: SIMD Considered Harmful MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-25 23:03 +0000
              Re: SIMD Considered Harmful EricP <ThatWouldBeTelling@thevillage.com> - 2026-09-27 11:33 -0400
                Re: SIMD Considered Harmful MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-28 00:04 +0000
                Re: SIMD Considered Harmful EricP <ThatWouldBeTelling@thevillage.com> - 2026-09-29 12:17 -0400
  Re: SIMD Considered Harmful Thomas Koenig <tkoenig@netcologne.de> - 2026-09-26 11:26 +0000
    Re: SIMD Considered Harmful Terje Mathisen <terje.mathisen@tmsw.no> - 2026-09-26 17:57 +0200
    Re: SIMD Considered Harmful BGB <cr88192@gmail.com> - 2026-09-26 13:52 -0500
      Re: SIMD Considered Harmful MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-26 21:24 +0000
    Re: SIMD Considered Harmful MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-26 21:16 +0000
  Re: SIMD Considered Harmful aph@littlepinkcloud.invalid - 2026-09-28 09:53 +0000

csiph-web