|
If you're debugging an optimized program, the debug info is probably wrong and giving you nonsense answers.
|
#
¿
Mar 13, 2008 04:45
|
|
|
|
| # ¿ May 7, 2024 08:08 |
|
|
There's nothing slow about std::vector; accessing it is exactly as fast as it's possible to be. DId he give any details on why it's slow? Does he just want to insert stuff into the middle of all his data structures?
|
|
#
¿
Apr 25, 2008 06:47
|
|
|
One of your printf formats is being ignored (probably because it doesn't like "%Lfx") so it's reading the wrong thing off the stack. And use %p instead of casting pointers to something else.
|
|
#
¿
May 1, 2008 16:33
|
|
|
Classes will usually have a vtable pointer at the beginning, so you can't rely on offsets from the beginning of the class. You can rely on offsets from other members, I guess. Also, use __attribute__((packed)) if you don't care about compiler portability, otherwise you'll forget to undo the #pragma and it'll be slow.
|
|
#
¿
May 5, 2008 23:29
|
|
|
JoeNotCharles posted:Actually you can in gcc - it's a compiler extension. (You shouldn't, though, because it makes your code non-portable.) It's legal C99, but that assumes a C99 compiler. vv That means they're not perfect (see the note), but I've never had any trouble with them in practice. Mr VacBob fucked around with this message at 20:22 on May 6, 2008 |
|
#
¿
May 6, 2008 18:50
|
|
|
gcc completely or mostly ignores 'inline' if you have optimizations on. Recent (4.3 or after) versions have decent inlining detection, but it was completely messed up before that. You really have to use __attribute__((always_inline)) sometimes.
|
|
#
¿
Jul 6, 2008 03:44
|
|
|
crazypenguin posted:The next biggest chunk for GCC is probably that the software architecture doesn't really lend itself to being changed very easily because god forbid somebody write a nonfree plugin for GCC! Quick! Chop our own arms off! This isn't true anymore, I wish people would stop acting like it was. There's at least two plugin APIs for GCC and a link-time optimization project coming along now. And the vectorization pass should be about as good or better as MS's; most of the problems come from parts being really old and full of awful spaghetti code written by RMS.
|
|
#
¿
Jul 14, 2008 06:14
|
|
|
-Wall in gcc will catch this. -Werror=implicit will catch it even better.
|
|
#
¿
Aug 13, 2010 09:46
|
|
|
slovach posted:What is with MSVC and SSE intrinsics? MS recommends their usage over inline asm, but the stuff it seems to generate is beyond earthly logic at times. The people who recommend MMX/SSE intrinsics over asm usually don't read their output asm. Of course, inline asm is kind of hard if you want MSVC/GCC compatibility, or even x86-32/x86-64 compatibility across the same compiler. "Instruction pairing" hasn't applied to anything since the first Pentium. Out-of-order x86 cores don't care what order your instructions are in (well...), so just to minimize instructions and register spills and don't worry about that. Mr VacBob fucked around with this message at 00:28 on Sep 10, 2010 |
|
#
¿
Sep 10, 2010 00:03
|
|
|
Nothing, they're identical. This is what C is for. Obviously you shouldn't try to free() it or anything.
|
|
#
¿
Sep 13, 2010 05:07
|
|
|
That program won't fail if you use -mfpmath=sse, but will if you use x87. Anything x86-64 and anything Darwin use SSE by default. Most non-x86 platforms should work too, because they aren't as horrible as x87 and don't extend float to double on loads.
|
|
#
¿
Nov 15, 2010 07:48
|
|
|
|
| # ¿ May 7, 2024 08:08 |
|
|
ehnus posted:PowerPC definitely extends 32-bit floats to 64-bit floats on load. Oh, so it does. I was thinking of double - x87 extends that to 80-bit, which breaks the PPC optimization of writing memcpy using double copies.
|
|
#
¿
Nov 16, 2010 21:51
|
|