Author: Robert Hyatt
Date: 07:52:36 01/18/04
Go up one level in this thread
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. > >> >>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.