[Developers] Modification to input of -cbs and -gbs
Allan.Hicks at noaa.gov
Allan.Hicks at noaa.gov
Mon Aug 23 10:19:57 PDT 2010
I believe that you are right, but I have never used size_t. There are
quite a few discussions of the advantages and disadvantages of size_t,
but it is seems to be implemented as a way to improve portability,
especially between systems. Here is one interesting article:
When compiled with MS 2008 32-bit compiler, size_t is 4 bytes (same as
int and long), but when compiled with MS 2008 64-bit, size_t is 8 bytes
(same as long long).
My questions are, would this require substantial recoding of the
gradstack and cmpdiff code to properly incorporate size_t? And, in the
interim, is my suggestion of the quick fix (int to long) a useful
change to incorporate since it doesn't appear to break the code and
appears to allow for more memory allocation in Linux?
----- Original Message -----
From: dave fournier <davef at otter-rsch.com>
Date: Thursday, August 19, 2010 11:03 am
Subject: Re: [Developers] Modification to input of -cbs and -gbs
> Allan Hicks wrote:
> I think the right way to do this is to find the correct type for
> lengths and use it. Don't recall what it is but there are types
> size_t and pos_t etc.
> They will automatically be defined to be the right type so you
> using the wrong int type and having to worry about it.
> > Ian Taylor and I just posted a document discussing the results of
> > testing different values of cbs and gbs for a large ADMB model
> > One thing that we learned is that when using the command line to
> > -gbs and -cbs (and -ams) it uses an integer data type. However,
> > seems that the code for the calculations associated with the
> > (excuse my ignorance) uses a long data type. This limits the
> > to values less than 2^31 and a total memory allocation around
> > Linux uses 64-bits to store long integers, thus we made a simple
> > change to how the command line inputs are read in (used long) and
> > able to allocate 12Gb to an ADMB program. However, Windows uses
> > 32-bits for a long integer, thus this change makes no difference
> > Windows (I have no clue about macs).
> > I made these changes to the xmodel3m.cpp file and attempted to
> > some Doxygen comments. I did not attempt to change any of the
> > allocation warnings in gs_set.cpp that still reference 16-bit
> > systems. I do not feel I understand the gradstack or cmpdiff
> > enough to do this intelligently.
> > I am wondering if this change would be useful to add to the
> > code, and I am curious of the process to make changes to the
> > code and how these changes are verified or moderated.
> > Thanks,
> > Allan
> > ------------------------------------------------------------------
> > _______________________________________________
> > Developers mailing list
> > Developers at admb-project.org
> > http://lists.admb-project.org/mailman/listinfo/developers
More information about the Developers