Author: Landon Rabern
Date: 14:43:34 05/08/00
Go up one level in this thread
On May 08, 2000 at 14:46:27, Christophe Theron wrote:
>On May 08, 2000 at 04:28:15, Dan Newman wrote:
>
>>On May 08, 2000 at 02:35:32, Landon Rabern wrote:
>>
>>>On May 08, 2000 at 01:52:18, David Blackman wrote:
>>>
>>>>On May 08, 2000 at 00:32:39, Robert Hyatt wrote:
>>>>
>>>>>On May 07, 2000 at 19:27:11, Landon Rabern wrote:
>>>>>
>>>>>>When compiling with Maximize Speed on in release mode in MSVC++ 6.0 I run at
>>>>>>about 190,000 nps, but in DJGPP with max optimizations I can get around 330,000
>>>>>>nps in the same position. Isn't Visual C++ supposed to be faster? Any ideas on
>>>>>>whats going on?
>>>>>>
>>>>>>Thanks,
>>>>>>
>>>>>>Landon W. Rabern
>>>>>
>>>>>
>>>>>I would suspect you are not getting all the MSVC optimizations turned on
>>>>>correctly. It is clearly better than GCC...
>>>>
>>>>It does depend a bit on what the program is doing. There are apparently some
>>>>looks that GCC does a better job on. To get such a big advantage for GCC on a
>>>>whole program would be extremely unusual though. Is this a well-known program?
>>>>Otherwise it might be interesting to post a couple of small fragments that you
>>>>think are the "inside loops" of the program, so we can see if you are doing
>>>>anything unusual that might favour GCC.
>>>
>>>Well according to the profile, this block takes up the most time.
>>>
>>
>><snip>
>>>
>>>Thats a rather large block
>>
>>Well, I didn't look very closely at the code, but I did notice the
>>malloc's and free's. If this is in the search function (or anything
>>else that's frequently called), the malloc's and free's will probably
>>really cost you... (OTOH, you are getting a pretty high node rate.)
>>
>>It could be that MSVC's malloc and free are simply a lot more expensive
>>than DJGPP's. Anyway, I'd try to eliminate the dynamic memory allocation...
>>
>>-Dan.
>
>
>Dan is right. mallocs and frees are probably slowing you down significantly.
>
>Try this:
>
>
>Somewhere in your global declarations:
>
> unsigned char mystack[50000];
>
>(you must figure out by yourself what is the right size for this array)
>
>
>At the start of your search:
>
> void *mystackptr = mystack;
>
>
>Instead of stuff=malloc(sizeof(*stuff)), do:
>
> stuff=mystackptr; mystackptr+=sizeof(*stuff);
>
>
>Instead of free(stuff), do:
>
> mystackptr-=sizeof(*stuff);
>
>
>You could also write macros or inline function to replace malloc and free. For
>example:
>
> void * INLINE mymalloc(int size) {
> void *p;
>
> p=mystackptr;
> mystackptr+=size;
> return(p);
> }
>
>
>I think it will work in your case because it looks like you are using your
>allocations in a LIFO way. It's a recursive search after all, so I would bet all
>allocations are LIFO (or can be turned into LIFO).
>
>However, be careful that this rule is always respected. Because if you do
>a=malloc(x) followed by b=malloc(y), then later free(a), you also free the 'b'
>block at the same time! (BTW this can actually be a speedup in some cases!)
>
>
>
> Christophe
Thanks, now up to about 450,000 nps in GCC, but still slow in VC++
Landon
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.