Whar are the effects of 4 meg of RAM?

Daniel

I'm not 100% sure, but I believe the amount of RAM affects how much virtual memory you can allocate.

I have 4GB of Ram on my laptop, and 3Gb on my desktop, and can notice the difference.

Mike Lucey

I have 4 on the MacBook Pro and I think it help with running
Parellels 3!

Mike

basic.woodworks

I have an older PC (single processor/Pentium 4) with XP on it. I installed 4 512Mb DDR2 RAM cards in it and she's able to multi task a lot better, and experiences a lot less slow downs when using larger on more demanding programs. Whenchecking the stats on the hardware, it reads the full 2048Mb of ram.

Don't know how it works with Skp. Because her hard drive is getting pretty ful, he doesn't want to install anymore programs than she already has.

Al Hart

You can use dumpbin.exe to determine if a program can handle large addresses and therefore take advantage of more than 2GB of ram (if you set the /3GB flag.

SketchUp.exe cannot handle large addresses.

Here is the report from dumpbin when run on dumpbin.exe

FILE HEADER VALUES
14C machine (x86)
3 number of sections
45712B6B time date stamp Sat Dec 02 01:29:47 2006
0 file pointer to symbol table
0 number of symbols
E0 size of optional header
123 characteristics
Relocations stripped
Executable
Application can handle large (>2GB) addresses
32 bit word machine

Here is the report from dumpbin when run on SketchUp.exe:

FILE HEADER VALUES
14C machine (x86)
4 number of sections
4753D734 time date stamp Mon Dec 03 04:15:16 2007
0 file pointer to symbol table
0 number of symbols
E0 size of optional header
10F characteristics
Relocations stripped
Executable
Line numbers stripped
Symbols stripped
32 bit word machine

SketchUp.exe does not have the "Application can handle large (>2GB) addresses" flag.

kwistenbiebel

That sucks

Go imagine that when you have a render plugin embedded in SU, it needs to share the amount of RAM (= less than 2 GB).
No wonder that things become buggy when trying to render slightly bigger scenes.

Al Hart

I know. I want to see if there is a way to run the renderer in a separate process, rather than in a DLL. That would let us use the full 2 GIG for just the rendering.

Our original renderer "RPS Ray Trace", also based on AccuRender used to run as a separate process. But many things were much better when we started running it as a DLL instead.

But it might be worth trying to switch back.

@kwistenbiebel said:

That sucks

Go imagine that when you have a render plugin embedded in SU, it needs to share the amount of RAM (= less than 2 GB).
No wonder that things become buggy when trying to render slightly bigger scenes.

dtrarch

Hi All

Both Win 2k and XP will access 3.4 GB of ram.(if you have 4GB installed)
Just find BOOT.ini and add the /3GB switch at the
end of the string....../fastopen/3GB

Just go to system properties (win key+pause break) to check.

dtr

kwistenbiebel

@al hart said:

I know. I want to see if there is a way to run the renderer in a separate process, rather than in a DLL. That would let us use the full 2 GIG for just the rendering.

Our original renderer "RPS Ray Trace", also based on AccuRender used to run as a separate process. But many things were much better when we started running it as a DLL instead.

But it might be worth trying to switch back.

The biggest disadvantage of the bad RAM adressing in su is the geometry export phase when hitting the render button (I guess no matter which render plugin one uses).
That's the moment when things go really bad when having higher poly models.
While it is exporting the mesh, you can see the RAM usage going through the roof and I always pray it will be finished before the limit is reached..otherwise the crashes are guaranteed.
To be honest I can't imagine the export phase to be a seperate process as it clearly needs to exchange info with SU while it is doing that.
In some cases it could be a benefit that export would be done in phases, in 'chunks', so the RAM can be cleared somewhere in between. The generated mesh .xml files could automatically be merged into one geometry file.

I don't know if what I describe is possible.....

Al Hart

@dtrarch said:

Hi All

Both Win 2k and XP will access 3.4 GB of ram.(if you have 4GB installed)
Just find BOOT.ini and add the /3GB switch at the
end of the string....../fastopen/3GB

Just go to system properties (win key+pause break) to check.

dtr

But a single process, like SketchUp, can only access more than 2GB of RAM if it is compiled and linked to access large memory (> 2GB). It looks like SketchUp was not built to handle large memory.

Al Hart

@kwistenbiebel said:

In some cases it could be a benefit that export would be done in phases, in 'chunks', so the RAM can be cleared somewhere in between. The generated mesh .xml files could automatically be merged into one geometry file.

I don't know if what I describe is possible.....

What we would do is write the geometry to a file - this is what exporters like KT do - and then read the file with a separate process. So the RAM usage during export would be minimal.

However, we want to make sure that the two processes are communicating. For instance if we change brightness settings in the render window, we want to remember those settings in SketchUp so we can reuse them.

Or, If you change the view or some other setting - like sun brightness - in SketchUp you would like to modify the rendering without saving and reloading the geometry.

We are researching the best way to have two separate processes be aware of each other and communicate, and then we will run some tests - such as exporting a large model to a file - to see if it will be of value to separate the processes.

(But this thread is not just about rendering - we have similar problems in our export to 3D PDF application, in our Component Reporting application, etc.)