Testing /Largeaddressaware property in SU 8

Stinkie

@unknownuser said:

is that why exporting in SUmac used to be superior?
[just curious]

No, by definition, Macs are superior.

Popcorn, anyone?

Jim

@jhauswirth said:

Try-
Test.eat_mem(# bytes)
I know the Ruby scripters like to snoop where they shouldn't (i.e. find undoc'd Ruby commands) so they would have eventually found this.

Should we just put your name on the BugSplats?

Al Hart

The page you reference says this:

@unknownuser said:

The first thing most developers notice is that 64-bit processors provide a huge leap in the amount of physical and virtual memory that can be addressed.
* 32-bit applications on 32-bit platforms can address up to 2 GB
* 32-bit applications built with the /LARGEADDRESSAWARE:YES linker flag on 32-bit Windows XP or Windows Server 2003 with the special /3gb boot option can address up to 3 GB. This constrains the kernel to only 1 GB which may cause some drivers and/or services to fail.
* 32-bit applications built with the /LARGEADDRESSAWARE:YES linker flag on the 32-bit editions of Windows Vista, Windows Server 2008, and Windows 7 can address memory up to the number specified by the boot configuration data (BCD) element IncreaseUserVa. IncreaseUserVa can have a value ranging from 2048, the default, to 3072 (which matches the amount of memory configured by the /3gb boot option on Windows XP). The remainder of 4 GB is allocated to the kernel and can result in failing driver and service configurations.

  For more information about BCD, see Boot Configuration Data on MSDN.
* 32-bit applications on 64-bit platforms can address up to 2 GB, or up to 4 GB with the /LARGEADDRESSAWARE:YES linker flag.
* 64-bit applications use 43 bits for addressing, which provides 8 TB of virtual address for applications and 8 TB reserved for the kernel.
Beyond just memory, 64-bit applications that use memory-mapped file I/O benefit greatly from the increased virtual address space. The 64-bit architecture also has improved floating-point performance and faster passing of parameters. Sixty-four-bit processors have double the number of registers, of both general purpose and streaming SIMD extensions (SSE) types, as well as support for SSE and SSE2 instruction sets; many 64-bit processors even support SSE3 instruction sets.

This implies to me that LAA is of some value on 32 but processors as well.

@thomthom said:

@al hart said:

Also, I was trying this on a 32 but Windows 7 processor. I may need to try it on a 64-but processor.

Yes - LAA is beneficial only for 64bit users. And you must have at least 4GB RAM.

For technical information: http://msdn.microsoft.com/en-us/library/ee418798%28v=vs.85%29.aspx

Now, I've never run into a case where SU itself ran out of memory. But when I rendered with V-Ray for SketchUp which runs inside the SketchUp process I have had memory issues. With LAA on I've rendered scenes where SketchUp.exe consumed 3GB+ RAM.

jeff hammond

@unknownuser said:

@jhauswirth said:

@unknownuser said:

is that why exporting in SUmac used to be superior?
[just curious]

No, by definition, Macs are superior.

Popcorn, anyone?

Al Hart

I ran this about 10 times and SketchUp did not get any larger.

 Test.eat_mem(40000000)

@jhauswirth said:

Try-
Test.eat_mem(# bytes)
I know the Ruby scripters like to snoop where they shouldn't (i.e. find undoc'd Ruby commands) so they would have eventually found this.

Al Hart

I started this separate thread because I did not want to Hijack the SU 8 Upgrade thread

Are you guys trying to hijakck this thread?

@unknownuser said:

@unknownuser said:

@jhauswirth said:

@unknownuser said:

is that why exporting in SUmac used to be superior?
[just curious]

No, by definition, Macs are superior.

Popcorn, anyone?

jeff hammond

@al hart said:

Are you guys trying to hijakck this thread?

yeah.. doing my best to prevent you from finding the answer to your question..

i'll stay away though.

Al Hart

AHA! I found the answer to one of my questions - How to enable Vista and Windows 7 to use more address space:

Note: This will make sense for 32-bit processors with 3GB or 4GB RAM

@unknownuser said:

Windows Vista and Windows 7 no longer use the BOOT.INI file, so there is a different method for setting the "3GB" switch which enables to use 3GB of RAM for applications in 32-bit Windows (otherwise they use just 2GB - maximum).

If you want to make accessible 3GB RAM for your CAD applications in Vista/Win7, use the BCDedit.exe tool (Boot Configuration Data Editor). The 3GB memory mode can be enabled with the command:

bcdedit /set IncreaseUserVa 3072

and disabled by the command:

bcdedit /deletevalue IncreaseUserVa

Run this command from a command window with Administrator priviledge - i.e. (in the Start menu) type CMD and press Ctrl+Shift+Enter, or select "Command Prompt" (Accessories), right-click on it and choose "Run as Administrator".

Restart your PC after this change.

I just made the setting. Now I need to reboot to see if it let me use more address space.

Stinkie

@al hart said:

Are you guys trying to hijakck this thread?

Just kidding around, Al.

thomthom

@al hart said:

This implies to me that LAA is of some value on 32 but processors as well.

If you enable the 3G switch - but you won't get the full advantage as running under 64bit does.

Al Hart

@thomthom said:

@al hart said:

This implies to me that LAA is of some value on 32 but processors as well.

If you enable the 3G switch - but you won't get the full advantage as running under 64bit does.

Yes, but I tried to throw a switch on my 32-bit machine to make it run in 64-bit mode, but I couldn't find the switch.

honoluludesktop

Al, What about the warnings regarding use on 32 bit systems: "...........kernel to only 1 GB which may cause some drivers and/or services to fail. ...............). The remainder of 4 GB is allocated to the kernel and can result in failing driver and service configurations....... ". Don't see the value in failing services and drivers, or do I misunderstand?

Al Hart

@honoluludesktop said:

Al, What about the warnings regarding use on 32 bit systems: "...........kernel to only 1 GB which may cause some drivers and/or services to fail. ...............). The remainder of 4 GB is allocated to the kernel and can result in failing driver and service configurations....... ". Don't see the value in failing services and drivers, or do I misunderstand?

I was explaining this whole thing to one of our clients:

In general, LAA is not going to make things any faster. The only time it comes into play is when SketchUp actually runs out of memory, which would cause a Bug Splat, or error message. In that case LAA might help you process the larger database.

There have been reports that SketchUp is simply faster for large models with LAA. But I would be surprised if this were true.

Is is very hard to test any of this.

honoluludesktop

OK got it. Thanks.

thomthom

@honoluludesktop said:

Al, What about the warnings regarding use on 32 bit systems: "...........kernel to only 1 GB which may cause some drivers and/or services to fail. ...............). The remainder of 4 GB is allocated to the kernel and can result in failing driver and service configurations....... ". Don't see the value in failing services and drivers, or do I misunderstand?

When I has 32bit windows and tried teh 3G switch I found the system to become a bit flakey.

jhauswirth

@al hart said:

In general, LAA is not going to make things any faster. The only time it comes into play is when SketchUp actually runs out of memory, which would cause a Bug Splat, or error message. In that case LAA might help you process the larger database.

Its like putting a bigger gas tank in your car- it will make you go further, but tell me why this would make your car faster?

thomthom

I like how everything can be explained in car analogies.

Evan

Increasing the amount of application memory at the expense of system memory isn't likely to address memory problems in Windows XP 32 bit. It isn't the general application paged pool memory that runs out in most cases. Applications that have a Graphical User Interface must allocate GDI OBJECTS and USER OBJECTS (GDI=Graphics Device Interface). There are limits on the number of such objects that may be created by any single process and there is also an overall per session limit. Per session means a session desktop for a logged on user.

SketchUp makes heavy use of such objects. Other applications such as Windows Explorer and Internet Explorer are also very heavy users. When the maximum limit for User Object or GDI Objects is approached the system will begin to degrade. It doesn't usually crash but certain functions such as the clipboard and right-click context menus will stop working.

You can see here how many objects are being allocated by various processes:

The only way to recover the ram used by these objects is to close the apps that are using the space available. Internet explorer is particularly bad in this respect. Firefox isn't any better. The best browser that I have tested is Opera. It uses far fewer objects when multiple tabs are open.

Existing allocated GDI and USER objects will not be deallocated until all instances of an application are closed. The situation becomes even worse if Terminal Services is running. Then the GDI ram is allocated from the unpaged system pool instead of the general application paged pool and the number of allowable objects drops dramatically. In fact, if Terminal Services is running then using the Large Address switch on XP will make the situation much worse.

Bottom line: There is no benefit to using the Large address switch on Windows XP 32 bit and that probably includes the 64 bit version although I am not certain of that.

References:
Process explorer is a part of the Sysinternals Suite available here:
http://technet.microsoft.com/en-us/sysinternals/bb842062