It has been [0] days since the problem was the C compiler doing optimization fuckery with memcpy https://furry.engineer/@nil/113020070271450212
-
It has been [0] days since the problem was the C compiler doing optimization fuckery with memcpy https://furry.engineer/@nil/113020070271450212
-
@mcc @nil From the point of view of a compiler guy … 99% of programs do use normal libc, and there is so much legacy code out there with stupid little memcpy routines somebody wrote that are now slow compared to what the compiler can generate inline or libc memcpy. I apologize for people who actually know what they are doing getting zapped but this is why we do it.
-
@acsawdey @nil It makes sense why you do it, but as a person who tends to write the kind of software where this Matters, it does screw with me kinda bad! I think James's question here is a good one if this isn't already a warning. https://don.rag.pub/@raggi/113020872059357145
-
@acsawdey @nil I once lost A LOT OF TIME, like weeks or months of time, to investigating a situation where we'd implemented our own memcpy() that was atomic on pointer words, and the compiler was just substituting the normal by-byte memcpy, and this was causing random crashes at random intervals at a low but distinctly detectable rate for everyone running software written in [programming language name redacted] on [platform name redacted] for most of a year
-
-
@mcc the function name doesn't matter (except possibly to *exempt* functions named exactly "memcpy" from this behavior in some implementations); this optimization isn't really there to replace functions that are Just Memcpy with memcpy() calls, it's there to replace code *within* a function that's Just Memcpy with a memcpy call; that includes manually copying arrays, assigning to large aggregates, etc.
-
Erin 💽✨replied to Ridley @ WATCH LYCORECO last edited by