12:30 "[ISA] do not matter very much"

By: dmcq (dmcq.delete@this.fano.co.uk), February 26, 2021 3:23 pm
Room: Moderated Discussions
Andrey (andrey.semashev.delete@this.gmail.com) on February 25, 2021 1:34 pm wrote:
> Linus Torvalds (torvalds.delete@this.linux-foundation.org) on February 25, 2021 10:35 am wrote:
> > Andrey (andrey.semashev.delete@this.gmail.com) on February 25, 2021 3:06 am wrote:
> > >
> > > memcpy can afford language like "undefined behavior", which is where most its liberties come from. I don't
> > > think an actual hardware instruction can afford that. The ISA must specify the instruction behavior in
> > > every use case, even though in some cases that behavior might be patologic or a hardware exception.
> >
> > For things like access size or memory ordering issues, implementation-defined
> > behavior is not the exception, it's the norm. x86 actually has fewer of them
> > than most, but even x86 already has them as part of the architecture.
> >
> > Look at instructions like "clear cacheline" (or invalidate it) that exist in many
> > many different architectures. It's not "undefined", but the instruction does different
> > things on different microarchitectures with different line sizes.
>
> Well, cache isn't part of architectural state, at least not on x86, so its properties
> and behavior are largely QoI and need not be specified in all details.
>
> ISAs specify how cache invalidation instructions work, and arguably say that they, well, evict the cache
> line. That the size of the cache line is different on different CPUs is a separate matter entirely.
>
> > That's the kind of microarchitectural effect that I'd suggest a memcpy instruction
> > does: the actual access size is implementation-defined. Not undefined.
>
> You must mean the maximum access size, since given that memcpy must operate on unaligned
> memory regions of byte-grained sizes the actual access size must come down to one byte.
> Tricks with out of bounds accesses won't work because of potential concurrency issues.
>
> The max access size greater than 1 you already have with "rep movsb", which may internally use 16-byte
> or larger transfers while maintaining byte-granular architectural behavior. It doesn't look like max access
> size is the problem. The important part is that the architectural grain size is well defined, so one can
> reason about memory contents at different points of its operation regardless of the implementation. For
> example, which parts of memory are guaranteed to be copied when a hardware exception happens? This is important
> because the software may have to swap out the page that is supposed to be processed.
>
> There is also the access order that's important. Not just to be able to reason about the memory state
> and behavior in case of overlap, but it may also affect performance. Like, depending on the copying
> order, the order of page faults could change, which could lead to a different access pattern to the
> page file. Or it may or may not introduce performance penalty caused by address aliasing.
>
> Then, there is effect on the cache. Although, as I said above, cache isn't part of architectural state (at
> least, not on x86), it is obviously important for performance, and the developer will most likely want to
> know how the memcpy instruction affects it. Will it keep the data hot? Which data - the initial or the last
> copied? Will it bypass the cache and simply invalidate the outdated cache lines? Something else?
>
> You see, software developers would want to know these kind of things to use the instruction
> appropriately. An underspecified memcpy instruction would not be useful because it
> would potentially mean different things on different CPUs. memcpy function also has
> this problem, and it is one of the reasons it gets reinvented so often.
>
> > It's a hell of a lot better than "clear cacheline", which is an actual dangerous
> > instruction to use, because not only does it have different access patterns,
> > it has actual different semantics on different microarchitectures.
> >
> > A "memcpy" instruction only has access pattern differences, not actual semantic differences. You can see
> > the access size in the overlap case, but that's no different from using a load/store sequence - the only
> > issue is that now the load/store size is just a microarchitectural feature (and typically it would be
> > the cache line size, but it could easily be just the "cache access size" which may be smaller).
> >
> > Seriously, if you think a memcpy instruction is questionable, you should immediately stop using
> > every single machine you have. Those "invalidate cacheline" instruction issues have caused
> > actual real and present problems, because they are much worse than what I suggested.
> >
> > Google "A tale of an impossible bug".
>
> An interesting tale indeed. It doesn't invalidate my point though. I mean, cache line size is naturally
> CPU-specific, and different cache line sizes on different kinds of cores are clearly possible (though
> I'm not convinced that it's sane). Cache manipulation instructions are naturally aligned to the cache
> line size, nothing unreasonable there. The problem here is not the instructions, its the historical software
> expectations of the hardware that no longer hold true. We can argue whether heterogeneous CPU cores is
> a good thing or not, but it is not really relevant to ISAs and instruction definitions.
>

Personally I think sometimes people just make things just a bit too simple. I think the zeroing operation should have been given a start and end address and be able to be put into a loop without needing to know anything about cache sizes.
< Previous Post in ThreadNext Post in Thread >
TopicPosted ByDate
New Lex Fridman interview with Jim KellerJohnG2021/02/19 11:25 PM
  12:30 "[ISA] do not matter very much" (NT)Moritz2021/02/20 09:45 AM
    AAARGH, what are we going to argue about then? (NT)j2021/02/20 02:43 PM
    Blasphemy! (NT):]2021/02/21 04:49 AM
    12:30 "[ISA] do not matter very much"anon22021/02/21 10:25 PM
      12:30 "[ISA] do not matter very much"Brett2021/02/21 11:59 PM
        12:30 "[ISA] do not matter very much"Etienne Lorrain2021/02/22 01:17 AM
      12:30 "[ISA] do not matter very much"Dummond D. Slow2021/02/22 08:57 AM
        12:30 "[ISA] do not matter very much"Anon2021/02/22 10:52 AM
          12:30 "[ISA] do not matter very much"juanrga2021/02/22 11:01 AM
          12:30 "[ISA] do not matter very much"Mark Roulo2021/02/22 11:54 AM
          ARM being a good idea doesn't mean it would have worked for AMDDummond D. Slow2021/02/22 01:34 PM
            ARM being a good idea doesn't mean it would have worked for AMDAnon2021/02/22 03:25 PM
              ARM being a good idea doesn't mean it would have worked for AMDDummond D. Slow2021/02/22 04:55 PM
                ARM being a good idea doesn't mean it would have worked for AMDDoug S2021/02/23 12:03 PM
                  ARM being a good idea doesn't mean it would have worked for AMDDummond D. Slow2021/02/23 12:27 PM
                    ARM being a good idea doesn't mean it would have worked for AMDBrett2021/02/23 03:57 PM
                      3rd parties licensing ARM coresAnon2021/02/25 04:01 AM
                        3rd parties licensing ARM coresAnon2021/02/25 04:48 AM
                        3rd parties licensing ARM coresdmcq2021/02/25 06:01 AM
                          3rd parties licensing ARM coresDummond D. Slow2021/02/25 09:17 AM
                            3rd parties licensing ARM coresAnon2021/02/25 10:11 AM
                              3rd parties licensing ARM coresAnon2021/02/26 02:54 AM
                              3rd parties licensing ARM coresDummond D. Slow2021/02/26 10:01 AM
            ARM being a good idea doesn't mean it would have worked for AMDLinus Torvalds2021/02/22 05:06 PM
              ARM being a good idea doesn't mean it would have worked for AMDDummond D. Slow2021/02/22 07:19 PM
              ARM being a good idea doesn't mean it would have worked for AMDanon22021/02/22 07:28 PM
              ARM being a good idea doesn't mean it would have worked for AMDdmcq2021/02/23 05:35 AM
                ARM being a good idea doesn't mean it would have worked for AMDJukka Larja2021/02/23 07:12 AM
                  ARM being a good idea doesn't mean it would have worked for AMDSimon Farnsworth2021/02/23 08:42 AM
                    ARM being a good idea doesn't mean it would have worked for AMDJukka Larja2021/02/24 06:03 AM
                ARM may have been a threat to Intelwumpus2021/02/23 08:30 AM
      12:30 "[ISA] do not matter very much"blaine2021/02/22 09:37 AM
        12:30 "[ISA] do not matter very much"anon22021/02/22 07:17 PM
          12:30 "[ISA] do not matter very much"Anon2021/02/23 03:05 AM
            12:30 "[ISA] do not matter very much"Wilco2021/02/23 03:48 AM
              12:30 "[ISA] do not matter very much"Bigos2021/02/23 03:55 AM
                12:30 "[ISA] do not matter very much"Wilco2021/02/23 04:15 AM
                  12:30 "[ISA] do not matter very much"Bigos2021/02/23 05:16 AM
                12:30 "[ISA] do not matter very much"Travis Downs2021/02/26 11:46 PM
              12:30 "[ISA] do not matter very much"Anon2021/02/23 06:26 AM
                12:30 "[ISA] do not matter very much"anon22021/02/23 04:35 PM
                  12:30 "[ISA] do not matter very much"Anon2021/02/24 07:57 AM
                12:30 "[ISA] do not matter very much"Wilco2021/02/24 04:37 AM
                  12:30 "[ISA] do not matter very much"Etienne Lorrain2021/02/24 06:24 AM
                    12:30 "[ISA] do not matter very much"Anon2021/02/24 08:11 AM
                    12:30 "[ISA] do not matter very much"rwessel2021/02/24 08:45 AM
                      12:30 "[ISA] do not matter very much"Etienne Lorrain2021/02/25 01:02 AM
                        12:30 "[ISA] do not matter very much"rwessel2021/02/25 04:51 AM
                        12:30 "[ISA] do not matter very much"Anon2021/02/25 04:53 AM
                  12:30 "[ISA] do not matter very much"Anon2021/02/24 08:07 AM
                    12:30 "[ISA] do not matter very much"Wilco2021/02/24 11:37 AM
                      runtime selection vs. heterogenous cores?Matt Sayler2021/02/24 06:10 PM
                        runtime selection vs. heterogenous cores?Wilco2021/02/26 05:22 AM
            12:30 "[ISA] do not matter very much"anon22021/02/23 04:20 AM
              12:30 "[ISA] do not matter very much"Anon2021/02/23 06:21 AM
                12:30 "[ISA] do not matter very much"none2021/02/23 07:37 AM
                  12:30 "[ISA] do not matter very much"rwessel2021/02/23 09:44 AM
                    12:30 "[ISA] do not matter very much"anon22021/02/23 04:30 PM
                      12:30 "[ISA] do not matter very much"Anon2021/02/24 08:25 AM
                        12:30 "[ISA] do not matter very much"anon.12021/02/25 06:13 AM
                  12:30 "[ISA] do not matter very much"Anon2021/02/24 08:44 AM
                12:30 "[ISA] do not matter very much"anon22021/02/23 03:51 PM
                  12:30 "[ISA] do not matter very much"Anon2021/02/24 08:31 AM
            12:30 "[ISA] do not matter very much"vvid2021/02/23 06:41 AM
              12:30 "[ISA] do not matter very much"Michael S2021/02/23 08:52 AM
                12:30 "[ISA] do not matter very much"rwessel2021/02/23 09:33 AM
                  12:30 "[ISA] do not matter very much"Linus Torvalds2021/02/23 11:44 AM
                    12:30 "[ISA] do not matter very much"rwessel2021/02/23 12:21 PM
                      12:30 "[ISA] do not matter very much"Linus Torvalds2021/02/23 12:30 PM
                        12:30 "[ISA] do not matter very much"Andrey2021/02/25 03:06 AM
                          12:30 "[ISA] do not matter very much"Anon2021/02/25 05:04 AM
                            12:30 "[ISA] do not matter very much"Andrey2021/02/25 05:54 AM
                              12:30 "[ISA] do not matter very much"Anon2021/02/25 06:33 AM
                          12:30 "[ISA] do not matter very much"Linus Torvalds2021/02/25 10:35 AM
                            12:30 "[ISA] do not matter very much"Andrey2021/02/25 01:34 PM
                              12:30 "[ISA] do not matter very much"Etienne Lorrain2021/02/26 01:18 AM
                              12:30 "[ISA] do not matter very much"dmcq2021/02/26 03:23 PM
                12:30 "[ISA] do not matter very much"Anon2021/02/24 08:45 AM
              12:30 "[ISA] do not matter very much"Gabriele Svelto2021/02/23 09:15 AM
          Context of ISA doesn't matterPaul A. Clayton2021/02/26 12:03 PM
  Is there a text version? (NT)Foo_2021/02/20 04:33 PM
    good question (NT)Michael S2021/02/21 04:31 AM
    Is there a text version?:]2021/02/21 10:34 AM
Reply to this Topic
Name:
Email:
Topic:
Body: No Text
How do you spell avocado?