glob2-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [glob2-devel] gradient improvement


From: Kai Antweiler
Subject: Re: [glob2-devel] gradient improvement
Date: Thu, 06 Apr 2006 21:41:28 +0200
User-agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Jumbo Shrimp, linux)

>> Yes, but the distance to the nearest resource of two fields in listedAddr
>> can at maximum differ by 1.
>
> Sorry, I don't get what you mean here ?

Ignore this comment.  I mixed things up.  I don't know the AI code.


> Do you have another suggestion for the fall back ?


For now we are fine.  But if we choose to optimize the size, we
should use something like:

After:  (line 2280)
        while (listCountRead < listCountWrite) 
        { 

Put:
                // Check if listedAddr could have an overflow 
                // The current field can spawn 8 fields at maximum 
                if(listCountWrite+8>=listCountRead+size) 
                { 
                        size_t oldsize=size; 
                        FILE *MapLog = globalContainer->logFileManager->getFile\
("Map"); 
                        fprintf(MapLog, "changed size to %d, Resource Type: %d\\
n", size, ressourceType); 
                        size>>1; 
                        Tint *listedAddr2 = new Tint[size]; 
                        for(int i=0; i<=oldsize; i++) 
                                *listedAddr2[i]=listedAddr[(i+listCountRead)&ol\
dsize]; 
                        delete listedAddr; 
                        updateGlobalGradientVersionSimple<Tint>(gradient, liste\
dAddr2, listCountWrite-listCountRead, gradientType); 
                        size<<1; 
                        return; 
                } 


If we make size high enough that the overflow will almost never happen,
the overhead will not worsen the runtime much.
But this handling is not beautiful.


> Which space you want to save?
> I see two things:
> -1- Computing the listedAddr[] of forbidden gradients differently.
> Yes, that's a good idea. Go ahead and test it!
> -2- Reducing the size when we can guess it will not overflow.
> I'm not sure I want this, but if it shows exceptional speedup I'll take it 
> into
> account. Go ahead and test it! (again)

I mean both.  And I will test both - sometime.


>>>Sounds ok to you ?

> Anyway the worst exploit ever will be the AI to make bad choices at
> long ranges.

I have closed the bug today.

-- 
Kai Antweiler





reply via email to

[Prev in Thread] Current Thread [Next in Thread]