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

By: Andrey (andrey.semashev.delete@this.gmail.com), February 25, 2021 2:34 pm
Room: Moderated Discussions
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.
< Previous Post in ThreadNext Post in Thread >
TopicPosted ByDate
New Lex Fridman interview with Jim KellerJohnG2021/02/20 12:25 AM
  12:30 "[ISA] do not matter very much" (NT)Moritz2021/02/20 10:45 AM
    AAARGH, what are we going to argue about then? (NT)j2021/02/20 03:43 PM
    Blasphemy! (NT):]2021/02/21 05:49 AM
    12:30 "[ISA] do not matter very much"anon22021/02/21 11:25 PM
      12:30 "[ISA] do not matter very much"Brett2021/02/22 12:59 AM
        12:30 "[ISA] do not matter very much"Etienne Lorrain2021/02/22 02:17 AM
      12:30 "[ISA] do not matter very much"Dummond D. Slow2021/02/22 09:57 AM
        12:30 "[ISA] do not matter very much"Anon2021/02/22 11:52 AM
          12:30 "[ISA] do not matter very much"juanrga2021/02/22 12:01 PM
          12:30 "[ISA] do not matter very much"Mark Roulo2021/02/22 12:54 PM
          ARM being a good idea doesn't mean it would have worked for AMDDummond D. Slow2021/02/22 02:34 PM
            ARM being a good idea doesn't mean it would have worked for AMDAnon2021/02/22 04:25 PM
              ARM being a good idea doesn't mean it would have worked for AMDDummond D. Slow2021/02/22 05:55 PM
                ARM being a good idea doesn't mean it would have worked for AMDDoug S2021/02/23 01:03 PM
                  ARM being a good idea doesn't mean it would have worked for AMDDummond D. Slow2021/02/23 01:27 PM
                    ARM being a good idea doesn't mean it would have worked for AMDBrett2021/02/23 04:57 PM
                      3rd parties licensing ARM coresAnon2021/02/25 05:01 AM
                        3rd parties licensing ARM coresAnon2021/02/25 05:48 AM
                        3rd parties licensing ARM coresdmcq2021/02/25 07:01 AM
                          3rd parties licensing ARM coresDummond D. Slow2021/02/25 10:17 AM
                            3rd parties licensing ARM coresAnon2021/02/25 11:11 AM
                              3rd parties licensing ARM coresAnon2021/02/26 03:54 AM
                              3rd parties licensing ARM coresDummond D. Slow2021/02/26 11:01 AM
            ARM being a good idea doesn't mean it would have worked for AMDLinus Torvalds2021/02/22 06:06 PM
              ARM being a good idea doesn't mean it would have worked for AMDDummond D. Slow2021/02/22 08:19 PM
              ARM being a good idea doesn't mean it would have worked for AMDanon22021/02/22 08:28 PM
              ARM being a good idea doesn't mean it would have worked for AMDdmcq2021/02/23 06:35 AM
                ARM being a good idea doesn't mean it would have worked for AMDJukka Larja2021/02/23 08:12 AM
                  ARM being a good idea doesn't mean it would have worked for AMDSimon Farnsworth2021/02/23 09:42 AM
                    ARM being a good idea doesn't mean it would have worked for AMDJukka Larja2021/02/24 07:03 AM
                ARM may have been a threat to Intelwumpus2021/02/23 09:30 AM
      12:30 "[ISA] do not matter very much"blaine2021/02/22 10:37 AM
        12:30 "[ISA] do not matter very much"anon22021/02/22 08:17 PM
          12:30 "[ISA] do not matter very much"Anon2021/02/23 04:05 AM
            12:30 "[ISA] do not matter very much"Wilco2021/02/23 04:48 AM
              12:30 "[ISA] do not matter very much"Bigos2021/02/23 04:55 AM
                12:30 "[ISA] do not matter very much"Wilco2021/02/23 05:15 AM
                  12:30 "[ISA] do not matter very much"Bigos2021/02/23 06:16 AM
                12:30 "[ISA] do not matter very much"Travis Downs2021/02/27 12:46 AM
              12:30 "[ISA] do not matter very much"Anon2021/02/23 07:26 AM
                12:30 "[ISA] do not matter very much"anon22021/02/23 05:35 PM
                  12:30 "[ISA] do not matter very much"Anon2021/02/24 08:57 AM
                12:30 "[ISA] do not matter very much"Wilco2021/02/24 05:37 AM
                  12:30 "[ISA] do not matter very much"Etienne Lorrain2021/02/24 07:24 AM
                    12:30 "[ISA] do not matter very much"Anon2021/02/24 09:11 AM
                    12:30 "[ISA] do not matter very much"rwessel2021/02/24 09:45 AM
                      12:30 "[ISA] do not matter very much"Etienne Lorrain2021/02/25 02:02 AM
                        12:30 "[ISA] do not matter very much"rwessel2021/02/25 05:51 AM
                        12:30 "[ISA] do not matter very much"Anon2021/02/25 05:53 AM
                  12:30 "[ISA] do not matter very much"Anon2021/02/24 09:07 AM
                    12:30 "[ISA] do not matter very much"Wilco2021/02/24 12:37 PM
                      runtime selection vs. heterogenous cores?Matt Sayler2021/02/24 07:10 PM
                        runtime selection vs. heterogenous cores?Wilco2021/02/26 06:22 AM
            12:30 "[ISA] do not matter very much"anon22021/02/23 05:20 AM
              12:30 "[ISA] do not matter very much"Anon2021/02/23 07:21 AM
                12:30 "[ISA] do not matter very much"none2021/02/23 08:37 AM
                  12:30 "[ISA] do not matter very much"rwessel2021/02/23 10:44 AM
                    12:30 "[ISA] do not matter very much"anon22021/02/23 05:30 PM
                      12:30 "[ISA] do not matter very much"Anon2021/02/24 09:25 AM
                        12:30 "[ISA] do not matter very much"anon.12021/02/25 07:13 AM
                  12:30 "[ISA] do not matter very much"Anon2021/02/24 09:44 AM
                12:30 "[ISA] do not matter very much"anon22021/02/23 04:51 PM
                  12:30 "[ISA] do not matter very much"Anon2021/02/24 09:31 AM
            12:30 "[ISA] do not matter very much"vvid2021/02/23 07:41 AM
              12:30 "[ISA] do not matter very much"Michael S2021/02/23 09:52 AM
                12:30 "[ISA] do not matter very much"rwessel2021/02/23 10:33 AM
                  12:30 "[ISA] do not matter very much"Linus Torvalds2021/02/23 12:44 PM
                    12:30 "[ISA] do not matter very much"rwessel2021/02/23 01:21 PM
                      12:30 "[ISA] do not matter very much"Linus Torvalds2021/02/23 01:30 PM
                        12:30 "[ISA] do not matter very much"Andrey2021/02/25 04:06 AM
                          12:30 "[ISA] do not matter very much"Anon2021/02/25 06:04 AM
                            12:30 "[ISA] do not matter very much"Andrey2021/02/25 06:54 AM
                              12:30 "[ISA] do not matter very much"Anon2021/02/25 07:33 AM
                          12:30 "[ISA] do not matter very much"Linus Torvalds2021/02/25 11:35 AM
                            12:30 "[ISA] do not matter very much"Andrey2021/02/25 02:34 PM
                              12:30 "[ISA] do not matter very much"Etienne Lorrain2021/02/26 02:18 AM
                              12:30 "[ISA] do not matter very much"dmcq2021/02/26 04:23 PM
                12:30 "[ISA] do not matter very much"Anon2021/02/24 09:45 AM
              12:30 "[ISA] do not matter very much"Gabriele Svelto2021/02/23 10:15 AM
          Context of ISA doesn't matterPaul A. Clayton2021/02/26 01:03 PM
  Is there a text version? (NT)Foo_2021/02/20 05:33 PM
    good question (NT)Michael S2021/02/21 05:31 AM
    Is there a text version?:]2021/02/21 11:34 AM
Reply to this Topic
Name:
Email:
Topic:
Body: No Text
How do you spell avocado?