| Re: memory issues redux [message #41573 is a reply to message #41571] |
Tue, 16 November 2004 10:33   |
Karl Schultz
Messages: 341
Registered: October 1999
|
Senior Member |
|
|
"R.G.Stockwell" <noemail@please.com> wrote in message
news:2vspuaF2ocjacU1@uni-berlin.de...
> I'm trying to squeeze out as much of my ram as I can.
> The threads here have helped a lot, but I still have a couple issues
> and questions:
> [win xp pro sp2, 3.4ghz p4, 4gb ram]
>
> 1) I'm not clear as to the status of idlde being able to access the 3gb
> memory
> space (by changing the boot ini file to include a /3g command).
> Can v6.11 do that? Is idl "Large Address Space Aware" ?
No, no current version of IDL (including 6.1.1) is Large Address Space
Aware.
But see additional discussion later on in this post.
> If I could get this working, that would be fantastic. I have not tried
> messing around with my boot ini file yet.
If you do this, be extremely careful.
Don't just add the /3GB switch to the currently active OS.
Copy the active entry and add the /3GB switch. Then you'll get a choice at
boot time.
That part of my boot.ini looks like this:
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP
Professional" /fastdetect
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP
Professional" /fastdetect /3GB
C:\bootfc1n.lnx="Fedora Core 1 (Yarrow)"
On my machine, I got an immediate blue screen in 3GB mode. So, I was glad I
made it an option on the boot menu.
I strongly suspect that one my drivers, probably the video driver, is the
problem.
When I get a chance, I can try to boot in VGA mode and/or try a different
video card. But I'm not optimistic because it is likely that another driver
might have a problem. There have been quite a few reports on the internet
about the difficulty in getting /3G working and its poor stability when it
does. But if I get anywhere, I'll let you know.
> 2) I used the editbin program to rebase the dlls, and saw no difference
> in the largest array possible. My best is a whimpy 940mb array.
> Is there any way to figure out what is going on in my ram, to see what
> dlls are loaded where, etc? Anyone know of a program that can defrag ram?
> I've googled and downloaded several ram defragers, but they don't have any
> effect on memory (in fact, they all see that I have 2gb of ram, and that
> I'm using
> 0kb if it). I also came accros a tech article saying that these types of
> programs
> are just a scam. So anyone know of a real program to manage ram? Or at
> least
> look at the ram to see what is loaded where?
I loaded IDL with the MS Visual Studio and looked at the module locations
after starting the IDLDE:
ug3220.dll 00220000-0023B000
MesaGLU6_2.dll 00240000-0028F000
MesaGL6_2.dll 00290000-003F4000
idlde.exe 00400000-005DB000
osmesa6_2.dll 009D0000-009DA000
freetype2_1_3.dll 009E0000-00A2C000
msvcr70d.dll 00A30000-00AB5000
LMAAG2DA.DLL 01760000-017B0000
wingl32.dll 017B0000-017E0000
idl32.dll 10000000-10794000
-- 1 GB gap --
shell32.dll 4F510000-4FD21000
ddraw.dll 51000000-51047000
msvcp60.dll 55900000-55961000
uxtheme.dll 5AD70000-5ADA4000
mfc70enu.dll 5D360000-5D36E000
opengl32.dll 5ED00000-5EDC6000
glu32.dll 68B20000-68B3E000
SHLWAPI.DLL 70A70000-70AD9000
comctl32.dll 71950000-71A34000
ws2help.dll 71AA0000-71AA8000
ws2_32.dll 71AB0000-71AC5000
netapi32.dll 71C20000-71C6E000
winspool.drv 73000000-73023000
dciman32.dll 73BC0000-73BC6000
icmp.dll 74290000-74294000
oleacc.dll 74C80000-74CAC000
riched20.dll 74E30000-74E9A000
comdlg32.dll 763B0000-763F5000
iphlpapi.dll 76D60000-76D77000
secur32.dll 76F90000-76FA0000
oleaut32.dll 77120000-771AB000
ole32.dll 771B0000-772D4000
comctl32.dll 77340000-773CB000
version.dll 77C00000-77C07000
msvcrt.dll 77C10000-77C63000
user32.dll 77D40000-77DCC000
advapi32.dll 77DD0000-77E5D000
kernel32.dll 77E60000-77F46000
ntdll.dll 77F50000-77FF7000
rpcrt4.dll 78000000-78087000
msvcr70.dll 7C000000-7C054000
mfc70d.dll 7C140000-7C31C000
gdi32.dll 7F000000-7F041000
Now these are just the modules and there are certainly other things using
this memory. Just because there are gaps between modules doesn't mean that
anything is wrong. But there is an open area of just over 1G, which is
about the size of your best allocation. So, it sort of looks like you are
getting a pretty nominal result.
I know I had a really cool tool on an old NT machine that let me look at the
memory layout. I can't find it and I look for it again everytime this comes
up. But no, I don't think that there are RAM (actually virtual address)
defraggers. Such a program would have to know about every single reference
to a virtual address if something at that address got moved, and that's just
not practical in an OS like Windows.
This is one area where the 32-bit and 64-bit Unix's have an edge and this is
why people use them.
However,
If you do get /3GB to work on your machine, then you can modify the
idlde.exe file with the EDITBIN tool to turn on the Large Address Space
Aware flag and see what happens. (EDITBIN comes with MS developer tools
like Visual Studio). Of course I have to say that RSI doesn't support this
and I can't tell you what will happen. We do not turn this flag on be
default but we'll definitely consider it for future releases.
As pointed out in other messages in this thread, 32-bit IDL cannot allocate
a contiguous piece of memory larger than 2GB. It would take an enormous
amount of work to get into the 2GB-4GB zone with 32-bit IDL and one can
argue it isn't worth it when 64-bit OS's are available. 64-bit Linux is here
and 64-bit Windows is almost here.
So, getting the 3GB and Large Address Space Aware configuration going won't
let you make single arrays over 2GB in size, but it will let you make more
arrays of this size or smaller. Also, a 32-bit LASA application will likely
have access to 4GB of space when running on 64-bit Windows.
Hope this helps,
Karl
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
