Author: Andrew Dados
Date: 10:48:19 01/18/04
Go up one level in this thread
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. As you said one have to try and benchmark to know what works better for his program. >> >>> >>>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.