Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Optimising Memset and Memcpy

twitter.com

Post reply on HN
Print view View original

11–20 of 30 posts

Re: Optimising Memset and Memcpy

#11

Post by cout »

astrobe_ wrote: post #9
easytiger wrote: post #4

Earlier quoted context omitted.

Half the benchmarks i see posted here are done on AWS instances or the authors laptop with power stepping/cstates, unisolated cores etc etc likely all enabled too, let alone basic rigour around hardware specifics. We are very much entering the age where mechanical sympathy is waning

CPU makers add so many complicated features to let users optimize their programs that it takes too much knowledge for mere mortals to optimize their programs - That you have to rely on heuristics and measures, as it is usually and wisely advised, is a bit unsatisfying. That's sort of ironic, in a way. I used to do assembly and count cycles, but now I wouldn't dare; it's hardcore compiler and library makers stuff. It'…

I have hand-written asm for use in production code, and I would do it again. I also knew exactly what cpu my code would be running on. If I were publishing the code to run on a variety of hardware, I would be very cautious.

Writing your own crypto is very different; the stakes are higher if you get it wrong.

Re: Optimising Memset and Memcpy

#12

Post by eternalban »

nadav256 wrote: post #7
easytiger wrote: post #4

Earlier quoted context omitted.

Half the benchmarks i see posted here are done on AWS instances or the authors laptop with power stepping/cstates, unisolated cores etc etc likely all enabled too, let alone basic rigour around hardware specifics. We are very much entering the age where mechanical sympathy is waning

I guess that you are referring to other projects because the benchmarks in this repo use a stable seed, turbo disabled, physical machine, both random and stable sizes, etc.

What’s the story with the spikes for folly and your code in memcpy plots? They get chopped off and it’s not clear what number they hit. (Nice work, btw)

Re: Optimising Memset and Memcpy

#13

Post by ungamed »

nadav256 wrote: post #7
easytiger wrote: post #4

Earlier quoted context omitted.

Half the benchmarks i see posted here are done on AWS instances or the authors laptop with power stepping/cstates, unisolated cores etc etc likely all enabled too, let alone basic rigour around hardware specifics. We are very much entering the age where mechanical sympathy is waning

I guess that you are referring to other projects because the benchmarks in this repo use a stable seed, turbo disabled, physical machine, both random and stable sizes, etc.

Havn't read the article, but c-states and p-states are different to turbo disabled.

Re: Optimising Memset and Memcpy

#16

Post by CalChris »

wscott wrote: post #3

A whole page of benchmark results without even listing which x86 he was testing??? This varies a lot from one generation to the next and between Intel & AMD. There are a ton of tradeoffs that have to be made in the microarchitecture and in general the focus is real code and normal expected sizes rather than benchmarks. Big page multiples are common and then variable sized calls that can be totally unaligned and rando…

No. The post provides an artifact so that you can test it yourself on your configuration. Knowing how it performed on this particular stepping of that particular microarchitecture won't help you on yours. Yes, your mileage may vary because your mileage always varies, even when you drive from point A to point B twice.

Rant continued. I would prefer if the performance sections of papers were restricted to single paragraphs and that artifacts were required. When I'm reading papers I'm more interested in their ideas than in the third decimal place of the result on that given day on some machine I don't have. The Unix Timesharing System has no performance results. The Case For A Reduced Instruction Set Computer has no performance results. The notion that not only having results is somehow important but that providing the testing methodology and hardware configuration is also necessary is nonsense. It just lards up papers and a couple of years later the cited configuration is irrelevant.

The CRAY-1 Computer System has no performance results but its section on vector processing still rings true today. It's what the RISC-V vector extension uses.

Re: Optimising Memset and Memcpy

#17

Post by gpderetta »

nadav256 wrote: post #8
gpderetta wrote: post #5

Earlier quoted context omitted.

Also the benchmark do not seem to use the same set of sizes for all benchmarks (nor use a fixed random seed) so repeatability and comparability seem questionable. I guess if you run it often enough it could still give useful numbers, but I understand the author is picking the best run. Also I don't see to be any attempt at avoiding compiler optimisations. Benchmarking is hard

Grep the code for rand_reset. The code uses a fixed seed, fixed sizes for all programs, stable nop baseline, etc. also the pointer indirection blocks compiler optimizations.

Indeed. i looked at the benchmark itself, but not the RNG.

Re: Optimising Memset and Memcpy

#18

Post by 19528970941f »

CalChris wrote: post #16
wscott wrote: post #3

A whole page of benchmark results without even listing which x86 he was testing??? This varies a lot from one generation to the next and between Intel & AMD. There are a ton of tradeoffs that have to be made in the microarchitecture and in general the focus is real code and normal expected sizes rather than benchmarks. Big page multiples are common and then variable sized calls that can be totally unaligned and rando…

No. The post provides an artifact so that you can test it yourself on your configuration. Knowing how it performed on this particular stepping of that particular microarchitecture won't help you on yours. Yes, your mileage may vary because your mileage always varies, even when you drive from point A to point B twice. Rant continued. I would prefer if the performance sections of papers were restricted to single paragr…

It seems that if you're going to put in data, it should be done rigorously, otherwise, as you say, you're just, at best, distracting from the main idea.

Re: Optimising Memset and Memcpy

#19

Post by dietr1ch »

easytiger wrote: post #4
wscott wrote: post #3

A whole page of benchmark results without even listing which x86 he was testing??? This varies a lot from one generation to the next and between Intel & AMD. There are a ton of tradeoffs that have to be made in the microarchitecture and in general the focus is real code and normal expected sizes rather than benchmarks. Big page multiples are common and then variable sized calls that can be totally unaligned and rando…

Half the benchmarks i see posted here are done on AWS instances or the authors laptop with power stepping/cstates, unisolated cores etc etc likely all enabled too, let alone basic rigour around hardware specifics. We are very much entering the age where mechanical sympathy is waning

IMO there's too many things to get right and no easy standard way of doing it.

Is there at least a checklist? It should ideally be automated. IIRC there's some library, maybe BLAS, that at compile time computes some machine-specific constants and also refuses to do it if a few things are not right.

Re: Optimising Memset and Memcpy

#20

Post by jeffbee »

People will tend to focus on the micro-structure of the assembly programs but the takeaway I get from this and recent related work in LLVM is avoiding the PLT is good for an easy 20% win for small sizes, which tend to be the common case. I like the new LLVM memcpy that is just plain C++, and easy to read and understand.

https://github.com/llvm/llvm-project/blob/main/libc/src/stri...

Post reply on HN