Testing /Largeaddressaware property in SU 8

Al Hart

The latest version of SU 8 () adds the /Largeaddressaware property.

In this release, SketchUp is now built using the /Largeaddressaware property on the PC. This change allows SketchUp to potentially allocate/address more memory on 64-bit machines. (Note: 64-bit users must have at least 1.89 GB RAM to see any improvement, and improvement is only noticeable in areas where memory was a limiting factor (e.g exporting images).

This property allows SU 8 to address more than 1.89 GB RAM on some machines.

I decided to test this by trying to get ruby to use large amounts of RAM.

This is fairly easy. The following two commands:

$a1 = []
$a1[100000000] = 1

(100000000 is 100,000,000 - 100 million)
Uses up about 300,000,000 meg of ram.
(You can use Windows Task Manager to see how much RAM SketchUp is actually using)

You would think that if you tried this about 7 times, (using $a1, $a2, $a3, ...) then you could get Ruby to grab about 2 GB of RAM itself. However, it fails on the 4th try with the message: "Error: #<TypeError: can't modify frozen string>"

I suspect Ruby itself may not actually be able to handle that much memory.

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

thomthom

@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.

jhauswirth

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.

thomthom

jeff hammond

are apps running under osx automatically large address aware (or similar)?

is that why exporting in SUmac used to be superior?

[just curious]

jhauswirth

@unknownuser said:

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

No, by definition, Macs are superior.

Rich O Brien

Stinkie

@jhauswirth said:

@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.