The 2GB memory Gap problem

knockatoone wrote on 5/12/2010, 12:10 PM

David Knight - Not a new topic but can not find ealry post by Dave Knight so will ask questions here. In one of your post you had a para 2 = "Allow User apps access to more 2GB virtual Memory" and tell how to do this using "run" as administrator and typing in "BCDEdit/ set increaseuserva 3072 and hit enter & restart. I have this printed out - getting lots of errors trying to do as you say ="Envirnment variable increase userva 3072 not found" and am not sure how to get to be administrator in dos - It opens with "c:\user\John" - have tried what little I remember of those old commands but not getting anywhere - can you help with more step by step - it is my appreciation that opening up more memory for use by other apps might be a real "find" . Win 7 - 64 bit..
Thanks, John

Comments

david_f_knight wrote on 5/12/2010, 3:22 PM

There are a few issues here. Possibly the reason you are getting the particular error you are getting is because there may need to be a space between BCDEdit and the slash that follows it.

The second issue is that for you, with a 64-bit version of Windows, there is no need to enable the increase of user virtual address space at all, because by default 64-bit versions of Windows enable all 32-bit applications (such as Vegas Platinum 9) to have the maximum of 4GB virtual address space for user code. It is only 32-bit versions of Windows that have a default 2GB virtual address space limit for user code.

As for being administrator in DOS, that won't have anything to do with which directory is the current one (eg., C:\user\John). I don't have Windows 7 or Vista, so I'm not sure how you establish your credential as administrator when running any particular program. However, with Windows XP (what I use), when you find a program you want to execute through the start menu, if you right click on it you can select "Run as..." from the pop-up menu; maybe that approach would allow you to run the Command prompt (DOS window) as administrator in Windows 7.

Memory is a surprisingly complex issue in any complex operating system like Windows. For Windows, there are two separate issues regarding the amount of virtual address space available to user code. (1) what Windows enables for all applications, and (2) what each application requests for itself. The smaller of the two will be used for each application.

BCDEdit deals with the amount that Windows enables. You do not need to modify this amount for 64-bit versions of Windows, because Windows already enables the maximum possible amount of 4GB for any 32-bit application that also requests it.

For this issue, BCDEdit is therefore used only with 32-bit versions of Vista and Windows 7.

The other part is what each 32-bit application requests. That's up to the people that write each program to decide, but most or all 32-bit programming tools use as default the 2GB limit. In other words, it's an extra step for programmers to make it higher than 2GB, and it just usually doesn't get done unless it really needs to be done. CFFExplorer can be used to change it after the fact, regardless of what the programmers did. (Rarely, it must be 2GB.)

To summarize, for anyone that uses any 64-bit version of Windows, 32-bit applications will either have a 2GB or a 4GB virtual address space limit for user code depending on how each such program has been created. CFFExplorer can be used to change the flag in 32-bit program files that determines whether the 2GB or 4GB limit is used.

For any 32-bit version of Windows, all applications will have a 2GB virtual address limit for user code unless (1) Windows has enabled the 3GB limit, and (2) each program requests 3GB. (3GB is the maximum under 32-bit versions of Windows, not 4GB as in 64-bit versions of Windows.)

So, it's not worth trying to modify all your 32-bit applications to use >2GB of virtual address space for user code. There might be a very few specific 32-bit applications that could benefit from this change, though. If I was going to do it at all, I would only change one program at a time and thoroughly test it before deciding to continue.

knockatoone wrote on 5/13/2010, 9:09 AM

Thanks, but ..
Begs the question - why does it work so well in VMS9 in Win 7- 64 fix--- but it does so ... never mind..
FYI - In Win 7 -64 bit ,programs are installed in two "Programs" directories -one is just "Progams" and the other is "Programs (x86). I understand that the "x86" folder is where 32 bit programs are installed with 64 bit going into the plain "programs" folder - If this is correct then doing the CFFFexplorer drill might be worth while on those (x86) programs - one by one ??
Is there a way to tell if the 2 GB cap is applied to a given program or would you just find the ".exe" file and apply it and see what happens ??
Do not want to turn this into a Windows fixer forum but would appreicate a reply here... Thanks, K

david_f_knight wrote on 5/13/2010, 8:38 PM

Does the fix for VMSP9 actually make it render faster, or just more reliably? (It could make it faster, too, but I don't know if it actually does.)

The reason the fix for VMSP9 works (to fix the render crashes) is that it avoids triggering a bug in VMSP9. But that is very specific to VMSP9.

I don't know of any way to tell whether any 32-bit program has the 2GB cap set or not except by using CFFExplorer one at a time. However, it wouldn't be hard to write a program that tests all the programs within any given directory and report its findings en masse for any programmer familiar with the relevant issues. But, I think it a bit risky to make this change on a wholesale basis. I'd recommend trying it only on programs where there is a reasonable expectation that it might be beneficial. That is, only programs that are both slow and deal with huge datasets. Not many programs, especially Windows system programs, meet both criteria. The types of programs that might benefit are most likely to be scientific, engineering, video, animation, and maybe graphics and audio programs.

knockatoone wrote on 5/14/2010, 7:18 AM

Thanks for the explanation -guess if you can not render with out the fix (speed =0 ) then you have nothing to compare the after fix speed too.....

OK - will try applying theCFFExplorer 2GB fix to a couple of 32 bit programs and see what happens - assume I would apply to the ".exe" files??

K

david_f_knight wrote on 5/14/2010, 9:51 AM

Good point about trying to compare the speeds between a failed render and a successful one... though many people are able to render a significant portion of their project before the crash or freeze occurs (w/o the fix), so those people could try to time up to that point and then compare a render after the fix to the same point in the project.

The CFFExplorer >2GB "fix" is only a fix for VMSP9 (because it has a bug). Otherwise, the "fix" is simply a modification, because in general it fixes nothing. It is not a bug for a program not to have set the >2GB flag. Yes, in general, if I was going to make the >2GB modification to various 32-bit programs, I would only do so to .exe files, especially at first. Otherwise, things could get pretty involved because most .exe programs also execute .dll files, and any given .dll file can be executed by more than one .exe or other .dll file. Changing one may lead to unintended consequences with other programs that you are unaware of that also execute the same file. In general, you will be safer if you modify only third-party program files that are located within the Program Files directory structure. Though not a hard and fast rule, programs located there tend to be more isolated than programs and dlls located in the WINDOWS directory structure, particularly those provided by Microsoft. Microsoft dlls are a resource provided for use by any and all third party software developers, as well as for Microsoft itself. I don't recommend modifying any Microsoft dlls (you might not be able to anyway, because Microsoft protects many of them and will, I believe, automatically restore them the next time you boot your computer up if they have been modified).

Never the less, you might find some third-party 32-bit applications that are very slow and use huge datasets that do speed up after applying the >2GB modification to their .exe file, so it could be worth some time spent experimenting. I'd just keep my attention focused specifically on those few programs that might actually show a significant improvement.

knockatoone wrote on 5/15/2010, 1:29 PM

Thanks - good info and advise - I have afew things infront of trying this but will advise what I get - will stay with ".exe" in the Programs(x86) folder and stay away from anything from windows...
K