Large Address Aware
patience55
Posts: 7,006
Somewhere there was a suggestion for this utility [thank you to whoever made it] so I tried it and it works great for Hexagon!
The latest release has had a few issues on my laptop ... the "lines" being basically useless as you couldn't place them exactly where you wanted to.
So I ran its .exe through this utility; I also reset to factory setting [which basically is where it always was but...] and now it's working! I'm very happy about this. I like using "lines" to start certain clothing items and/or props for the characters.
http://www.techpowerup.com/forums/showthread.php?t=112556
Large Address Aware! It doesn't install ... the utility will simply run when you click on the .exe file.
It enables 32 bit .exe files you choose to use more of the available memory on a 64 bit computer. Not recommended if you have less than 3G available.
Daz 3D is part of 
Connect
DAZ Productions, Inc.
7533 S Center View Ct #4664
West Jordan, UT 84084
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
I was looking for this link to other day, thx for posting it here. I wanted it for Bryce, never thought of using it on Hex cheers. ;)
I have this as well and used it on Hex.
I've tried it with several of the older 32 bit programs [some were for XP some for W7] and so far no problems. They seem to open/close faster if nothing else.
Maybe you guru's can help me out? I have a single-core, 2.8Ghz machine, running Win32 XP Home, with 3 Gigs DDR RAM and a spare slot for another 1Gig stick. Would it be worth my while to install the extra Gig and do large address aware thing?
Even my local shops disagree - one saying yes and the other saying Windows can only access 3gigs, so another is pointless.
Editing reply. I reread their page ... if one uses it on a 32bit computer one needs to increase the user memory setting as per their instructions.
One also requires a minimum of 3Gigs of RAM. However I think more people are using this LAA who have the 64 bit and simply trying to get their old 32 bit programs working a bit better.
I do recall being told that XP could only handle so much memory the mother board being the deciding factor when I was upgrading it. Over time though it was money that I could have saved as I found myself seldom using the XP computer .... W7 is so much more stable with the programs I use. And when they want to crash ... it doesn't crash the OS. The OS offers to turn them off instead ;-)
Ram access gets really tricky, Roy. It has a fascinating history beginning in the old days when CPUs could only directly address a few megs of ram. Then a few industry leaders rolled up their sleeves and figured out a way of opening up sections of extended memory to the operating system using hardware trickery. These leaders were (L)otus, (I)ntel and (M)icrosoft, and the scheme was introduced as the "LIM standard". The LIM standard referred to extended memory accessed in such a way as "expanded memory", and the blocks of memory made accessible were called...wait for it..."windows"! And the rest, as they say, is history. :)
Over the years though, CPU/chipset technology has grown far more complex and are now capable of addressing terabytes (and even petabytes) of ram, while operating systems tended to lag behind. So the DATA structure in OSs increased from 8-bit to 16 to 32-bit systems, but MEMORY ADDRESSING INSIDE THE OS were limited. XP 32-bit OS was designed with 32-bit addressing (32-bit data and 32-bit addressing are 2 entirely different things; it's mere coincidence that they're the same number). Mathematically, 2^32 = 4GB, so 4GB is all the ram that XP x86 can address even though 32/64-bit hardware is capable of addressing larger amounts.
Now beyond that, all operating systems reserve blocks of ram for its own use, so it's impossible to access all the ram you have installed. In the case of XP x86, the OS reserves roughly half a gig for itself. So with your 3GB of ram, you have about 2 1/2 GB of ram available to you for running programs. With a full complement of 4GB installed, you would have about 3 1/2 GB of ram available.
On top of all that, we now have to look at memory ALLOCATION given by the OS to any given program which may be anywhere from a few megabytes to a few gigabytes depending on many variables.
I'm guessing that "large address aware" is usurping the OSs allocation and forcing its own allocation. Now by the program's own description, it can allocate up to 3GB to a program on a 32-bit OS, and I'm assuming that would be with 4GB installed.
And without knowing what the OS's allocation is for whatever program it is that you're running, it's hard to say whether adding another GB will help, although if you currently don't have any problems running the program, I doubt that increasing ram available to it would add much if anything for you.
I notice that the list he shows are primarily games. Games are a kind of "special class" of program that can tax the living hell out of ram and system resources far beyond anything that a program such as hexagon will demand. My system has a paltry 2GB of ram and it's never caused me any problems running anything - EXCEPT A GAME ONCE. :)
I can't remember what the game was, but it was one of those well-known "benchmark games" for testing your system for gaming. It may well have been "matrix", but I'm really not sure. Whatever it was, my system had a hard time keeping up with it, and it was very "jerky" to play. (As you might guess, I'm not a game player. I only have a single game I enjoy, and that's "quake II". I can hear the groans from here... :-) )
The funny thing is, I built my own system and got the fastest 2 gigs I could afford at the time, planning on adding more later. But as it turned out, everything I did on my system seemed to work fine with the 2 gigs and I just never got around to adding any more.
So now as I leave another verbose tome in my wake, I hope I've made some sense of memory for you, but even more I hope I haven't confused you. :)
Thanks for the replies - this makes it a lot clearer.
OK, so if I understand correctly, LAA is not on for Hex, but it COULD be worthwhile installing another Gig for general performance - about the only real problem I'm experiencing with anything is that DS 4.5 gets very laggy when I use the parameters. I don't use DS for anything but rigging and fitting clothing. Part of the rigging process is setting constraints and the lagginess really bugs me. Could this be a RAM issue ?- I have read that DS 4.5 is a real RAM hog.
It's possible, but there are other possibilities. CPU architecture, CPU speed (2.8ghz certainly sounds sufficient though) - or even the programming algorithm used to process the math. I refer you to hexagon's "smoothing function" that will bring any system to its knees at around 4 or 5, and yet something like blender does the same thing without batting a cyber-eyelash.
Yet another element that can cause lagging is slow ram. Ram is rated by a string of numbers that show access speeds of various ram parameters. They'll look like 2-2-2-5 (which is damned fast) or 7-7-7-12 (which is damned slow). Some ram are defined by 5 or 6 numbers, but they all reflect access times of various ram functions. The numbers are the number of clock cycles needed by the ram to set or recover from a specific state.
I should have noted before that the simplest way of discovering memory inadequacy is to watch for increased disk activity during a memory intensive function. The system has what's called a "pagefile" that keeps track of memory blocks. When it needs more room, it writes a block of ram to the pagefile and uses the freed-up ram to continue its function. In severe cases, your system will be reading and writing pagefile info at a frenzied pace, and your disk activity will be obvious (in many systems, even audible!). The pagefile is also what's called "virtual memory". Of course, pagefile swapping can also be cause by having multiple memory intensive programs running at the same time.
Too little ram is the main cause of pagefile swapping, while slow ram just inserts "wait states" (wastes clock cycles) during memory access.
Now I'm a geek, and geeks often waste time "thinking too hard" about things and such may be the case here. :)
If you PM me with a particular example or file that bogs down your DS4.5, I can do the same thing on my system and see if I get similar results.
Come to think of it, my DDR is three generations ago - blinding fast in it's time - like me.Lol
I've not noticed any disc activity - next time I do a rig - probably tomorrow - I'll keep an eye out on CPU usage and disc activity. Strangely enough, when I test the parameter sliders using Genesis, I don't get that lagging. Possibly something to do with memory build-up while rigging. I'll try completing the rigging, closing down, then starting the parameters and see if that my solve it.
If I still have a problem, I'll PM you the file for more of your Sherlock Holmes imitations.
Cheers
You have a standing invitation, sir!