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

[John Sibert]

Using size_t may be the best approach to writing truly portable 64-bit 
code. size_t is and unsigned type, so some care is necessary in doing 
arithmetic on variables ot type size_t. I notice that a special type for 
this purpose, ptrdiff_t, is available.

I was curious about how size_t is actually defined, so I scoured my 
ubuntu 10.04 64-bit laptop for the header file that defines size_t and 
failed to find it. It is not in stddef.h as claimed by some authorities. 
Does any one know where it is actually defined?

This as an important issue. Quite a few ADMB and AUTODIF applications 
would benefit by access to the full 64-bit address space. If someone 
wants to take it on, I'm sure there would be plenty of help from readers 
of this list.

John


On 08/23/2010 07:19 AM, Allan.Hicks at noaa.gov wrote:
> Thanks Dave,
>
> 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:
>
> http://www.eetimes.com/discussion/programming-pointers/4026076/Why-size-t-matters
>
> 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?
>
> Allan
>
> ----- 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
>> file
>> lengths and use it. Don't recall what it is but there are types
>> like
>> size_t and pos_t etc.
>> They will automatically be defined to be the right type so you
>> avoid
>> 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
>>>        
>> (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
>>>        
>>
>>      
> _______________________________________________
> 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/