[gdal-dev] Starting a discussion on style and coding guidelines

[Even Rouault]

Le jeudi 02 juin 2016 00:46:06, Kurt Schwehr a écrit :
> https://docs.google.com/document/d/1O1B7LY13L532kXcYcB2EdO65m5LOCsqaqn5R9iJ
> fSPU/pub
> 
> The optimized stack .o is 1248 bytes and the on the heap vector is 1600
> bytes with gcc 4.8.  The cost of either is pretty small.  So, if there are
> 100 of these in gdal, we are talking about 30-60K of extra object file size
> for all the cases in GDAL.

Code size is one thing, but I'd be curious to know about the speed impacts due 
to the heap allocation. Like time several million iterations of each way (and 
make sure to do something non trivial with the arrray so that the compiler 
doesn't optimize the code away). If there's no significant difference, then fine. 
Otherwise we'd have to be careful when the replacements are done in a 
performance sensitive routine (my feeling is that there are not so many such 
places)

> 
> For stack usage, start thinking about tons of threads spread out over lots
> of cores and think about how systems are built...  Google Compute Engine
> has 32 core machines.  If you want to get the most out your machines at
> scale, you want a small stack.
> 
> int anVals[256] = {};  Does initialize everything to the default value
> (zeros), but doesn't solve the stack issue.
> 
> Making a little class is yet another thing for people to learn when vector
> looks to me to work quite well.
> 
> On Mon, May 9, 2016 at 1:37 PM, Andrew Bell <andrew.bell.ia at gmail.com>
> 
> wrote:
> > On Mon, May 9, 2016 at 2:49 PM, Mateusz Loskot <mateusz at loskot.net> wrote:
> >> Point taken.
> >> 
> >> Although the proposal looks OK, I'd suggest to check what
> >> assembler code generates your favourite C++ toolkit,
> >> or at least measured times for
> >> 
> >> int anVals[256];
> >> memset(anVals, 0, 256*sizeof(int));
> > 
> > Are "we" doing memset anymore in these cases?
> > 
> > int anVals[256] = {};
> > 
> > seems preferable
> > 
> >> vs
> >> 
> >> std::vector<int> oVals(256, 0);
> >> 
> >> and compare with:
> >> 
> >> std::vector<char> oVals(256, 0);
> > 
> > Think vector is a bad solution for something that's fixed.  Just write
> > something.  But I already suggested that and wrote something... :)
> > 
> > Do you know why they are wedded to a 16K stack?
> > 
> > --
> > Andrew Bell
> > andrew.bell.ia at gmail.com
> > 
> > _______________________________________________
> > gdal-dev mailing list
> > gdal-dev at lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/gdal-dev

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com