Author Topic: Block copy instructions  (Read 21881 times)

0 Members and 1 Guest are viewing this topic.

Offline vad

  • Frequent Contributor
  • **
  • Posts: 700
  • Country: us
Re: Block copy instructions
« Reply #75 on: January 19, 2021, 01:16:30 am »
On the most modern systems block-copy performance is limited by the latency and throughput of RAM interface, and therefore a single block-copy CISC instruction would have no noticeable advantage over multiple RISC instructions.
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 6464
  • Country: nz
Re: Block copy instructions
« Reply #76 on: January 19, 2021, 02:19:34 am »
On the most modern systems block-copy performance is limited by the latency and throughput of RAM interface, and therefore a single block-copy CISC instruction would have no noticeable advantage over multiple RISC instructions.

Except most block-copy calls (and probably most bytes copied in block copies) are in sizes far smaller than typical L1 caches, so a CISCy instruction with lower start-up overhead than a RISC software loop (choosing the appropriate version of copy, initializing registers etc) could have an advantage.

Except Intel have finally recently gotten REP MOVSB faster than a software loop -- for large copies. If I understand certain web pages correctly, on Skylake and newer REP MOVSB takes 20 cycles for any copy less than 12 bytes, and has a 40 cycle startup overhead for any copy greater than 76 bytes, but then copies 64 bytes every 4 cycles.
 

Offline vad

  • Frequent Contributor
  • **
  • Posts: 700
  • Country: us
Re: Block copy instructions
« Reply #77 on: January 19, 2021, 02:51:48 am »
On the most modern systems block-copy performance is limited by the latency and throughput of RAM interface, and therefore a single block-copy CISC instruction would have no noticeable advantage over multiple RISC instructions.

Except most block-copy calls (and probably most bytes copied in block copies) are in sizes far smaller than typical L1 caches, so a CISCy instruction with lower start-up overhead than a RISC software loop (choosing the appropriate version of copy, initializing registers etc) could have an advantage.

Except Intel have finally recently gotten REP MOVSB faster than a software loop -- for large copies. If I understand certain web pages correctly, on Skylake and newer REP MOVSB takes 20 cycles for any copy less than 12 bytes, and has a 40 cycle startup overhead for any copy greater than 76 bytes, but then copies 64 bytes every 4 cycles.
Except cache still carries latency penalty. For example Skylake’s L1 Data cache latency is whooping 4 cycles per  operation (8 cycles in total, since you need to read and write). And that’s if you are lucky enough to have both source and destination rows in tiny L1 cache.
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 6464
  • Country: nz
Re: Block copy instructions
« Reply #78 on: January 19, 2021, 06:30:37 am »
On the most modern systems block-copy performance is limited by the latency and throughput of RAM interface, and therefore a single block-copy CISC instruction would have no noticeable advantage over multiple RISC instructions.

Except most block-copy calls (and probably most bytes copied in block copies) are in sizes far smaller than typical L1 caches, so a CISCy instruction with lower start-up overhead than a RISC software loop (choosing the appropriate version of copy, initializing registers etc) could have an advantage.

Except Intel have finally recently gotten REP MOVSB faster than a software loop -- for large copies. If I understand certain web pages correctly, on Skylake and newer REP MOVSB takes 20 cycles for any copy less than 12 bytes, and has a 40 cycle startup overhead for any copy greater than 76 bytes, but then copies 64 bytes every 4 cycles.
Except cache still carries latency penalty. For example Skylake’s L1 Data cache latency is whooping 4 cycles per  operation (8 cycles in total, since you need to read and write). And that’s if you are lucky enough to have both source and destination rows in tiny L1 cache.

Writes don't have latency. They go into a write queue immediately and you don't care what happens to them after that (unless you try to read the value back again before it gets written to L1 cache, in which case you get up to a 10 cycle penalty on Skylake and newer).
 

Online DiTBho

  • Super Contributor
  • ***
  • Posts: 5102
  • Country: gb
Re: Block copy instructions
« Reply #79 on: January 19, 2021, 09:31:49 am »
Write Through and Write Deferred (aka Write Back) in Cache

  • In Write Through, data is simultaneously updated to cache and memory.
    Read has no latency
    Write has latency
    The memory is coherent
  • In Write Deferred, data is updated only in the cache and updated into the memory in later time. Here there are several policies,  FIFO, LIFO and others depending on the application.
    read has no latency
    write has no latency
    The memory is not coherent

« Last Edit: January 19, 2021, 10:32:02 am by DiTBho »
The opposite of courage is not cowardice, it is conformity. Even a dead fish can go with the flow
 

Offline vad

  • Frequent Contributor
  • **
  • Posts: 700
  • Country: us
Re: Block copy instructions
« Reply #80 on: January 20, 2021, 02:37:06 am »
Writing to “Write Back” cache also could have latency. If the line that is being written to is not present in cache, the line will have to be loaded from the RAM first, unless the word that is being written has the size of the cache line and is perfectly aligned.
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 6464
  • Country: nz
Re: Block copy instructions
« Reply #81 on: January 20, 2021, 02:58:37 am »
Writing to “Write Back” cache also could have latency. If the line that is being written to is not present in cache, the line will have to be loaded from the RAM first, unless the word that is being written has the size of the cache line and is perfectly aligned.

Not if you have a store buffer.

(unless you have so many cache misses on write in a row that the store buffer backs up)
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf

 

-->