Author: Robert Hyatt
Date: 12:54:42 01/18/04
Go up one level in this thread
On January 18, 2004 at 13:48:19, Andrew Dados wrote: >On January 18, 2004 at 10:52:36, Robert Hyatt wrote: > >>On January 18, 2004 at 01:09:13, Andrew Dados wrote: >> >>>On January 17, 2004 at 12:24:59, Robert Hyatt wrote: >>> >>>>On January 17, 2004 at 07:14:35, Bo Persson wrote: >>>> >>>>>On January 16, 2004 at 22:35:55, Robert Hyatt wrote: >>>>> >>>>>>On January 16, 2004 at 22:15:34, Federico Corigliano wrote: >>>>>> >>>>>>>Hi >>>>>>> >>>>>>>In my engine I have a lot of #defines as: >>>>>>>#define FileA 0xFFFFFFFF <- I don't remember the real value >>>>>>>and I want to convert it to: >>>>>>>const UINT64 FileA = 0xFFFFFFFFF; >>>>>>>I the change can affect the speed. As I often use MSVC Debugger, it's boring to >>>>>>>translate every #define to the respective number. >>>>>>> >>>>>>>Federico >>>>>> >>>>>>I don't think there will be much difference. Using a #define might produce >>>>>>some asm code with 32 bit immediate values which will bloat the code a bit, >>>>>>while using the const int64 will plop one copy of the value in memory making >>>>>>it fit in cache maybe a bit better. >>>>> >>>>><nitpicking> >>>>>There is a minute difference between C and C++, in that const values have >>>>>internal linkage by default in C++ (in C that would be 'static const'). That >>>>>saves the compiler from having to store the value in memory, as it cannot be >>>>>accessed from other compilation units anyway. >>>>></nitpicking> >>>>> >>>> >>>>I hadn't thought about the static C option at all, bit irregardless there is >>>>still a question of use a #define to produce a huge instruction where at least >>>>the immediate will be available when the instruction is executed, or to use a >>>>memory reference where the instruction will be smaller and hopefully the data >>>>will be in cache. >>> >>>Not sure if 2 memory references (in 32bit mode) will produce shorter code then >>>immediate values. Most likely no savings at all, maybe even immediate value can >>>save some code size. That depends on how is the 64bit constant accessed and >>>used, and of course on mode of processor (32 vs 64). Note for some operations >>>immediate value is MUCH faster, then for some operations immediate value can't >>>be used at all. >>> >>>- Andrew- >> >>Here was my thinking. a 32 bit immediate value is stuck right in the >>instruction. And it is replicated everywhere it is needed. A 32 bit >>value can be stored on the stack, and accessed with a register + 8bit offset >>if you are lucky, which results in shorter code, a smaller footprint in the >>L1 I-cache, and probably better performance as the only one copy of the >>constant gets stuck in the L1 D-cache... >> >>But as I said, I would not depend on static analysis, I would always test >>this as there are lots of variables in where things get placed and how they >>are referenced. >> > >You have a point here but I doubt some global const in big program will be >addressed by 8bit offset. Definitely it will not be put on or accessed via sp >(stack) in any compiler I know (even if like in windoze ss and ds are the same >for the process). >Of course for local constants stack might be used and it is likely that [bp+8bit >offset] can be generated. I wasn't particularly talking about a "global constant". However, you can have 'em in a big struct and access it with a register + offset, and a small offset will make it shorter than a 32 bit immediate constant folded in to the instruction. > >As you said one have to try and benchmark to know what works better for his >program. Correct. And it is subject to change as you modify other parts of the code as well... > >>> >>>> >>>>There is probably some break-even point in how many times you use one or the >>>>other, before the other is preferable. I wouldn't try to predict without >>>>running it however. >>>> >>>>>> >>>>>>Best bet is to try it and see which is faster for _your_ program and machine. >>>>> >>>>>A good idea anyway. >>>>> >>>>> >>>>> >>>>>Bo Persson
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.