comp.lang.idl-pvwave archive
Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado

Home » Public Forums » archive » Re: Memory Headache II
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Switch to threaded view of this topic Create a new topic Submit Reply
Re: Memory Headache II [message #37819] Sun, 01 February 2004 00:48 Go to next message
David T is currently offline  David T
Messages: 2
Registered: February 2004
Junior Member
>
> Well, that is actually a 4 GB array. Who would have thought the error
> message might be misleading? (I'm starting to sound like David.)

What I want to know if there is a built in number of elements limit in
addition to a RAM addressing limitation? (never mind how that message
was triggered that time.)


>
>> 3) Does anyone have a finger in the wind as to when a full 64-bit
>> implementation of IDL might be available for *nix distributions?

>
> http://www.rsinc.com/services/techtip.asp?ttid=3635&wid= 4240&s=1497
>

Also, why do my arrays top out around 1.6 GB (when it uoght to be 2GB),
and why am I unable to allocate memory once the total has reached
about 3.6 GB ?

Thanks

David Theil
Re: Memory Headache II [message #37829 is a reply to message #37819] Fri, 30 January 2004 14:00 Go to previous messageGo to next message
K. Bowman is currently offline  K. Bowman
Messages: 330
Registered: May 2000
Senior Member
In article <300120041306434820%spam@me.and.die>,
David <spam@me.and.die> wrote:

> IDL's 32 bit implementation is supposed to be capable of 2 GB arrays.
> When I attempt to grab more than 2 GB using the new_ptr function I get
> the expected malloc errors. However, I find I get these errors even if
> I try to grab something like 1.6 or 1.7 GB; a value too far off to be
> attributable to whether a GB is 10^9 bytes or 2^30 bytes. Is there some
> unseen overhead at issue here? (I have experimented in detail to find
> out to the byte how far I can go, but do not have that info handy.)
>
> Another oddity occurs when I try to
>
> a=fltarr(1024,1024,1024,/noz)

Well, that is actually a 4 GB array. Who would have thought the error
message might be misleading? (I'm starting to sound like David.)

> Instead of the stream of malloc errors, I get something to the effect
> of "this array has too many elements" . Is there an element limit
> too? When I try
>
> a=bytarr(1024,1024,1024,/noz) the memory is allocated w/o a hitch.

That would be only 1 GB.

> 3) Does anyone have a finger in the wind as to when a full 64-bit
> implementation of IDL might be available for *nix distributions?

As you have discovered, although G5's are 64-bit chips, OS X is not
really a 64-bit OS yet. I would guess that will happen next Fall(?),
when 10.4 will probably be released.

RSI has a surprisingly straightforward page about platform support that
addresses 64-bitness on various platforms.

http://www.rsinc.com/services/techtip.asp?ttid=3635&wid= 4240&s=1497

At present, only 'real workstation' Unixes (HP, IBM, Sun, SGI,
Dec/Compaq) have 64-bit versions of IDL.

I hope RSI doesn't mind the quote:

When Will RSI Support 64-Bit IDL and ENVI For The G5 Mac?
RSI expects to support 64-bit IDL and ENVI for the G5 in due time, but
this will not happen immediately. In the meantime, we believe 32-bit IDL
will run very well on the new G5 hardware.

Apple has released the G5 hardware, which has a 64-bit architecture, but
several pieces still need to come together on the software side: the OS,
compilers, system libraries, etc. While there is plenty of hype out
there to confuse the issue, Mac OS X 10.3 (Panther) is still not a fully
64-bit operating system. Sources at Apple confirm that Panther does not
allow for 64-bit pointers in applications. This means that it is not yet
possible to compile IDL as a 64-bit application for the G5. This is
entirely understandable so soon after the G5 release. Those of you
familiar with other systems that made this transition (HP, SGI, Sun,
IBM) will recall that those systems first released 64-bit hardware,
followed by several releases of the OS before complete 64-bit support
was achieved. We expect Apple to follow a similar course.

Certainly Panther offers a few of the advantages of a 64-bit system. For
instance, each 32-bit application can separately use up to 2GB of
memory, whereas on 32-bit hardware there is 2GB of memory available for
all applications to share at any one time. This is a significant
improvement�and one that IDL can take advantage of as is.

RSI currently plans to support a 64-bit version of IDL and ENVI for the
Mac when it makes sense to do so. For the IDL 6.1 release, RSI will test
IDL on the G5 under Panther as a 32-bit application. ENVI 4.1, scheduled
for release after IDL 6.1, will follow suit.
Re: Memory Headache II [message #37918 is a reply to message #37819] Sun, 01 February 2004 07:05 Go to previous message
David Fanning is currently offline  David Fanning
Messages: 11724
Registered: August 2001
Senior Member
David T writes:

> Also, why do my arrays top out around 1.6 GB (when it uoght to be 2GB),
> and why am I unable to allocate memory once the total has reached
> about 3.6 GB ?

This whole topic was discussed on this newsgroup several
months ago. You can find pointers to several articles
and to the original discussion here:

http://www.dfanning.com/file_io/lgfiles.html

Cheers,

David
--
David W. Fanning, Ph.D.
Fanning Software Consulting, Inc.
Phone: 970-221-0438, E-mail: david@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155
  Switch to threaded view of this topic Create a new topic Submit Reply
Previous Topic: I can't clear breakpoints using idlwave_shell
Next Topic: Re: Rapid "moving windows" access in IDL?

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Sat Oct 11 13:40:25 PDT 2025

Total time taken to generate the page: 0.87801 seconds