Memory and 32 bit / 64 bit

classic Classic list List threaded Threaded
10 messages Options
JD JD
Reply | Threaded
Open this post in threaded view
|

Memory and 32 bit / 64 bit

Hello,

Doing tests between 32 bit and 64 bit build we found something that seems to be a defect in the management of memory of image layers.

Can be reproduced with osgearth_viewer gdal_tiff.earth. The memory occupied by the image is, in 64 bit, approximatively twice the size comparing to 32 bit.
It seems OK with feature models, only image layers have this trouble.

The memory gap seems to be in gdal library. We are trying to profile to point the source of the problem.
Note that I don't reproduce with QGIS 32 and 64 bit with the same GeoTiff (64 bit version is even better than the 32 bit).
We tried 8 bits GeoTiff and 32 bits GeoTiff with same result.

Osg 3.4.0 / OsgEarth 2.8 / GDal 2.2(dev 15-09-16) / MSVC (64 bit or 32 bit).

With very large image layers the memory gap can be huge and can make the difference with targets like iPad Mini with only 1GB of RAM.

Do you have any idea?

Thank you,
Jérôme.

remoe remoe
Reply | Threaded
Open this post in threaded view
|

Re: Memory and 32 bit / 64 bit

Hi

Can you please try this also with latest master of osgEarth?

Cheers
Remo Eichenberger, Switzerland, @crocomer
jasonbeverage jasonbeverage
Reply | Threaded
Open this post in threaded view
|

Re: Memory and 32 bit / 64 bit

Gdal uses a block cache to speed up image reads.   I wonder if the maximum size default is different for 64 vs 32 bit. 

I think the env var is  GDAL_CACHEMAX.   maybe look into that and see what you find.  

Also make sure your comparing release mode in both cases.  Don't test one on debug and one in release.   

Jason

On Jan 20, 2018 6:17 AM, "remoe [via osgEarth]" <[hidden email]> wrote:
Hi

Can you please try this also with latest master of osgEarth?

Cheers
Remo Eichenberger, Switzerland, @crocomer



If you reply to this email, your message will be added to the discussion below:
http://forum.osgearth.org/Memory-and-32-bit-64-bit-tp7591570p7591573.html
To start a new topic under osgEarth, email [hidden email]
To unsubscribe from osgEarth, click here.
NAML
JD JD
Reply | Threaded
Open this post in threaded view
|

Re: Memory and 32 bit / 64 bit

Jason your idea about gdal cache seems to be the good one.

In gdal source code, the default value for the cache is 5% of the max available RAM for the process.
The max available RAM for a Windows 32 bit process is 2 GB. On 64 bit there is not this limitation (all the remaining RAM on the system could be allocated). Thus it can explain the difference.

However even if I force GDAL_CACHEMAX to a value (i tried percent or absolute value) the consumed memory is not impacted (253 MB for annotation.earth at init).
Does OsgEarth have also this kind of "dynamic" maximum cache ?

I compiled the master in 64 bit and I have the same memory consumption as 2.8 64 bit. (not compiled in 32 bit yet...)

(and yes i am in release in all tests)
jasonbeverage jasonbeverage
Reply | Threaded
Open this post in threaded view
|

Re: Memory and 32 bit / 64 bit

Hey JD,

That was a good guess about GDAL then :)

That value will only effect GDAL layers (like loading a geotiff directly), not any other osgEarth layers.  osgEarth does have a memory cache that is in place for all layers that will store recently used images so that compositing tiles will be fast if any reprojection needs to be done.  By default this is set to 16, so unless you're using a ton of layers reducing it won't really effect memory that much.  You can try it though:
set OSGEARTH_L2_CACHE_SIZE=0

253MB at startup for annotation.earth is about what I get too, and it's not out of the ordinary.

Jason

On Mon, Jan 22, 2018 at 5:42 AM JD [via osgEarth] <[hidden email]> wrote:
Jason your idea about gdal cache seems to be the good one.

In gdal source code, the default value for the cache is 5% of the max available RAM for the process.
The max available RAM for a Windows 32 bit process is 2 GB. On 64 bit there is not this limitation (all the remaining RAM on the system could be allocated). Thus it can explain the difference.

However even if I force GDAL_CACHEMAX to a value (i tried percent or absolute value) the consumed memory is not impacted (253 MB for annotation.earth at init).
Does OsgEarth have also this kind of "dynamic" maximum cache ?

I compiled the master in 64 bit and I have the same memory consumption as 2.8 64 bit. (not compiled in 32 bit yet...)

(and yes i am in release in all tests)


If you reply to this email, your message will be added to the discussion below:
To start a new topic under osgEarth, email [hidden email]
To unsubscribe from osgEarth, click here.
NAML
JD JD
Reply | Threaded
Open this post in threaded view
|

Re: Memory and 32 bit / 64 bit

About annotation.earth I have only 88 MB at init! (everything loaded).

32bit

Exactly the same test case and I have 255 MB at init with 64 bit build.

64 bit

Is TMS driver using gdal?
If not the issue comes from elsewhere...
jasonbeverage jasonbeverage
Reply | Threaded
Open this post in threaded view
|

Re: Memory and 32 bit / 64 bit

That's really interesting, and I don't have a good explanation for it :)  I know the size of a pointer is going to be bigger in 64 bit, but I have a hard time believing that we're using 100MB of pointers on load :)  

Are you running on a highly memory constrained system and actually need a reduction in memory or are you just noting differences between 32 and 64 bit?  

Basically you should always run 64 bit unless you have a great reason not to.  You can exhaust the memory of a 32 bit application very quickly once you start doing real work in your application, so 64 bit is definitely the way to go.

Jason

On Mon, Jan 22, 2018 at 1:06 PM JD [via osgEarth] <[hidden email]> wrote:
About annotation.earth I have only 88 MB at init! (everything loaded).

32bit

Exactly the same test case and I have 255 MB at init with 64 bit build.

64 bit

Is TMS driver using gdal?
If not the issue comes from elsewhere...



If you reply to this email, your message will be added to the discussion below:
To start a new topic under osgEarth, email [hidden email]
To unsubscribe from osgEarth, click here.
NAML
JD JD
Reply | Threaded
Open this post in threaded view
|

Re: Memory and 32 bit / 64 bit

Our project aims at working on windows surface pro and ipad. The ipad mini has only 1 GB of RAM. Today our application consumes too much memory. We defined list of possible improvments and 32 bit was an idea... We did not imagine such a result !
So this memory gap must be mastered...
I will let you know the results of our investigation.
JD JD
Reply | Threaded
Open this post in threaded view
|

Re: Memory and 32 bit / 64 bit

Some news about the investigation! :

- GDAL_CACHEMAX is not explaining the problem (it has an impact when displaying a tif for example but it does not impact the annotation.earth case)
- OSGEARTH_L2_CACHE_SIZE decreases the memory of approximatively 30 MB in 64 bit and nearly nothing on 32 bit (so it does not explain)
- In annotation.earth if we replace the terrain-gpu method by the terrain-map method, the memory reduces of 100MB while it has no impact on 32 bit ! On both cases the clamped line is corectly displayed.

For annotation.earth if looking at the debug log, we can observe that _numOfTextureObjects goes to 44 for 64 bit but only 27 in 32 bit (exactly same use case : init of annotation.earth).

Any new ideas?

Thanks.
remoe remoe
Reply | Threaded
Open this post in threaded view
|

Re: Memory and 32 bit / 64 bit