[Developers] Modification to input of -cbs and -gbs

Allan.Hicks at noaa.gov Allan.Hicks at noaa.gov
Thu Aug 19 20:22:18 PDT 2010

Hi John,

We posted the document on the compilers page of the benchmarks page of
the community page (reminds me about my promise to work on the website


Ian and I have been learning a lot about 64-bit, but we do not
understand enough of the nuances to really get a feeling for the
difficulty of porting ADMB to 64-bit.  What we do know, is that changing
a a few 'int' data types to 'long' for variables that read in command
line values allowed us to input values larger than 2^31 and Linux was
able to allocate over 12Gb of memory to a SS3 model.  So, it seemed to
work, although we have not done any thorough testing or comparisons.

Thanks for the link.  It is very interesting and helps me understand
things a little better (I'm particularly concerned that 32-bit systems
turn the date negative in 2038.  I'll start preparing for Y2-38 now.). 
My opinion is that the simple changes we made allow ADMB to work with
more memory in the Linux environment.  However, the Windows environment
would take a lot of work because everything in the cmpdiff stack and
gradstack would have to be recoded as 'long long' (from what I
understand of these concepts in ADMB).  

Thanks again for your input and I look forward to further discussions
with the developers.  I am not sure if this is an issue with other
users, but I know that a few of us doing assessments in SS3 with
multiple areas, fleets, ages, sexes, etc are beginning to push the
limits of 32-bit systems.  I feel that this may not be as high of a
priority as parallelization, but in terms of future requirements to keep
up with other optimization options, moving to 64-bit may be a necessity.
 In the short term, it may be useful to at least warn a user when an
input value exceeds INT_MAX in a 32-bit system.  There is code in place
to do this, but it doesn't always work due to the reading of a command
line value in as 'int' before the comparison.


----- Original Message -----
From: John Sibert <sibert at hawaii.edu>
Date: Thursday, August 19, 2010 5:32 pm
Subject: Re: [Developers] Modification to input of -cbs and -gbs

> Hi Alan -
> Thanks for your note. Where did you post your document?
> The 64-bit issue in ADMB could get complex and should be approached 
> carefully.  Johnoel sent me a useful link you might want to look 
> at: 
> http://www.ibm.com/developerworks/linux/library/l-port64.html
> Incidentally I just added the following functions to the AUTODIF 
> library 
> for saving and restoring pointers in the cmpdif stack:
> void save_pointer_value(void* ptr);
> void * restore_pointer_value(void);
> Cheers,
> John
> On 08/18/2010 11:38 AM, Allan Hicks wrote:
> > Ian Taylor and I just posted a document discussing the results of 
> > testing different values of cbs and gbs for a large ADMB model 
> (SS3).  
> > One thing that we learned is that when using the command line to 
> set 
> > -gbs and -cbs (and -ams) it uses an integer data type. However, 
> it 
> > seems that the code for the calculations associated with the 
> buffers 
> > (excuse my ignorance) uses a long data type.  This limits the 
> inputs 
> > to values less than 2^31 and a total memory allocation around 
> 2Gb.  
> > 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 
> were 
> > able to allocate 12Gb to an ADMB program.  However, Windows uses 
> > 32-bits for a long integer, thus this change makes no difference 
> in 
> > Windows (I have no clue about macs).
> >
> > I made these changes to the xmodel3m.cpp file and attempted to 
> add 
> > some Doxygen comments. I did not attempt to change any of the 
> memory 
> > allocation warnings in gs_set.cpp that still reference 16-bit 
> > systems.  I do not feel I understand the gradstack or cmpdiff 
> buffers 
> > enough to do this intelligently.
> > I am wondering if this change would be useful to add to the 
> source 
> > code, and I am curious of the process to make changes to the 
> source 
> > 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
> >    
> -- 
> John Sibert
> Emeritus Researcher, SOEST
> University of Hawaii at Manoa
> Visit the ADMB project http://admb-project.org/

More information about the Developers mailing list