Author: Andrew Dados
Date: 22:09:13 01/17/04
Go up one level in this thread
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- > >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.