 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
This question pertains to the way Pov-Ray for windows reports peak memory.
A scene I rendered this evening had 120k objects. I have 128 megs of
physical ram memory and about 250 megs of swap space available. The
128 megs of ram were consumed quickly and the swap file grew to nearly
220 megs before it finaly finished parsing the file. When I checked the
peak memory use after the image finished rendering however it only
reported using 128 megs of memory. Obviously the math does not work out
and I am wondering why there is such a descrepency between what I know
it to have used and what the program itself reports was used.
--
Ken Tyler
mailto://tylereng@pacbell.net
http://home.pacbell.net/tylereng/links.htm
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ken <tyl### [at] pacbell net> wrote:
: A scene I rendered this evening had 120k objects. I have 128 megs of
: physical ram memory and about 250 megs of swap space available. The
: 128 megs of ram were consumed quickly and the swap file grew to nearly
: 220 megs before it finaly finished parsing the file. When I checked the
: peak memory use after the image finished rendering however it only
: reported using 128 megs of memory. Obviously the math does not work out
: and I am wondering why there is such a descrepency between what I know
: it to have used and what the program itself reports was used.
I'm not sure, but perhaps it's due to windows and its memory management.
Perhaps it doesn't free immediately the memory freed by the program. Or
perhaps there are memory fragmentation problems.
Suppose this:
m1=allocate(100);
m2=allocate(50);
m3=allocate(100);
deallocate(m2);
m4=allocate(100);
First we allocate a total of 250 units. Let's suppose that they use
contiguous memory. Our "memory usage" and "peak memory use" variable is now
250 units.
Then we free m2, which is 50 units and our "memory usage" variable is now
200 units.
Then we allocate 100 units. Our "memory usage" goes to 300, which is bigger
than the old "peak memory use" so it becomes also that.
Now the system has to allocate 100 units but there's only a 50 unit hole
so it has to allocate it from the end (ie. after the m3 allocation). So
although the memory used is 300 units, 350 units of memory is needed to hold
them.
"Peak memory used" is now 300 units, but 350 units were needed to achieve
the operation.
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nieminen Mika wrote:
>
> Ken <tyl### [at] pacbellnet> wrote:
> : A scene I rendered this evening had 120k objects. I have 128 megs of
> : physical ram memory and about 250 megs of swap space available. The
> : 128 megs of ram were consumed quickly and the swap file grew to nearly
> : 220 megs before it finaly finished parsing the file. When I checked the
> : peak memory use after the image finished rendering however it only
> : reported using 128 megs of memory. Obviously the math does not work out
> : and I am wondering why there is such a descrepency between what I know
> : it to have used and what the program itself reports was used.
>
> I'm not sure, but perhaps it's due to windows and its memory management.
> Perhaps it doesn't free immediately the memory freed by the program. Or
> perhaps there are memory fragmentation problems.
> Suppose this:
>
> m1=allocate(100);
> m2=allocate(50);
> m3=allocate(100);
> deallocate(m2);
> m4=allocate(100);
>
> First we allocate a total of 250 units. Let's suppose that they use
> contiguous memory. Our "memory usage" and "peak memory use" variable is now
> 250 units.
> Then we free m2, which is 50 units and our "memory usage" variable is now
> 200 units.
> Then we allocate 100 units. Our "memory usage" goes to 300, which is bigger
> than the old "peak memory use" so it becomes also that.
> Now the system has to allocate 100 units but there's only a 50 unit hole
> so it has to allocate it from the end (ie. after the m3 allocation). So
> although the memory used is 300 units, 350 units of memory is needed to hold
> them.
> "Peak memory used" is now 300 units, but 350 units were needed to achieve
> the operation.
What a screwy way of doing business...
--
Ken Tyler
mailto://tylereng@pacbell.net
http://home.pacbell.net/tylereng/links.htm
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I think that most UNIXes have very good memory management (including Linux).
It's worth trying.
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nieminen Mika wrote:
>
> I think that most UNIXes have very good memory management (including Linux).
> It's worth trying.
I have thought seriously about it but every time I hear the words linux and
unix I also hear the words compiling and make files and such. This implies
to me that a compiler would be necessary and consequently a programmers
background to use it. I have neither the time nor inclination to learn how
to become a programmer at my age.
I really think UNIX'es are popular among college students and computer
industry professionals but I don't really think it is for the average Joe
computer user who cares little for how it works only that it does. Therein
lies the success story behind the Microsoft and Macintosh operation systems.
No rocket science involved behind it just pay the man some money, pop in
a disk to install the software, and away you go. Plus I enjoy the wealth
of Microsoft compatible software available for the platform I run on.
Maybe it's not a perfect system but it does work and I am comfortable in
it. My 30 year old Ford truck is not in perfect working order either but
it reliably gets me where I need to go and who could ask for more than
that ?
--
Ken Tyler
mailto://tylereng@pacbell.net
http://home.pacbell.net/tylereng/links.htm
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ken <tyl### [at] pacbellnet> wrote:
: I have thought seriously about it but every time I hear the words linux and
: unix I also hear the words compiling and make files and such. This implies
: to me that a compiler would be necessary and consequently a programmers
: background to use it. I have neither the time nor inclination to learn how
: to become a programmer at my age.
Who said you have to know C-programming to use UNIX? There's absolutely
no need.
And I think there are compiled versions of povray for Linux. And even if
you had to compile a custom version, you still don't need to know anything
about C-programming. Usually it's enough to just type "make newxwin" at the
command line.
: I really think UNIX'es are popular among college students and computer
: industry professionals but I don't really think it is for the average Joe
: computer user who cares little for how it works only that it does.
UNIX _is_ harder to learn than windows, but it's getting easier and
easier with all these Linux distributions which have all the fancy GUIs,
graphical configuration programs, etc. I'm not sure because I have never
used Linux, but I think that nowadays you can use most of its features
without ever having to type anything at the command line.
I think that the popularity of UNIX amongst professionals is that it
really is a good OS and you can do what you want instead of having to do
only what "they" allow you to do.
No GUI will ever get even close to command line tools like grep, sed,
perl, and all those handy UNIX tools. With just the sh-shell and a couple
of those tools you can make things that need a complete programming language
compiler/interpreter in Windows (this is absolutely great when making CGI
scripts, for example).
Of course a good GUI is very handy for many things. I use Win98 every day.
But I would feel very limited without 4DOS. (Actually I feel very limited
without all those handy unix tools...)
As someone has said, a child points at the thing he wants with his finger
while an adult says what he wants :)
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Like Nieminen said, it's probably poor memory management on the part of
Windows. Also, it takes memory to allocate memory... you have to say which
memory is being used by which programs and how big the various chunks are.
(similar to the file allocation table for allocating disk space)
Also don't forget that windows itself uses quite a bit of space. Most of
it is swapped out most of the time, but it still takes many, many megs and
will give you a large swap file.
-Nathan
Ken wrote:
>
> This question pertains to the way Pov-Ray for windows reports peak memory.
>
> A scene I rendered this evening had 120k objects. I have 128 megs of
> physical ram memory and about 250 megs of swap space available. The
> 128 megs of ram were consumed quickly and the swap file grew to nearly
> 220 megs before it finaly finished parsing the file. When I checked the
> peak memory use after the image finished rendering however it only
> reported using 128 megs of memory. Obviously the math does not work out
> and I am wondering why there is such a descrepency between what I know
> it to have used and what the program itself reports was used.
>
> --
> Ken Tyler
>
> mailto://tylereng@pacbell.net
> http://home.pacbell.net/tylereng/links.htm
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nathan Kopp wrote:
>
> Like Nieminen said, it's probably poor memory management on the part of
> Windows. Also, it takes memory to allocate memory... you have to say which
> memory is being used by which programs and how big the various chunks are.
> (similar to the file allocation table for allocating disk space)
It must be extremely poor memory management if it requires a 200 meg overhead
to operate in. The numbers are still not adding up even given what you and
Warp are saying. I run no programs when pov is operating. I have explorer
in the background and that is it. Memory reporting software tells me there
is 93% of physical ram available for use by the system and my swap file
when pov is not running never exceeds 20 megs in size. That leave 200 megs
for file allocation tables and poorly managed storage in the disk sectors ?
Oh well there is not much I can do about it but it seems it is time to get
a mother board that will support more that 128 megs of on board ram. I
have another 96 megs sitting in my desk doing nothing.
--
Ken Tyler
mailto://tylereng@pacbell.net
http://home.pacbell.net/tylereng/links.htm
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ken <tyl### [at] pacbellnet> wrote:
: That leave 200 megs
: for file allocation tables and poorly managed storage in the disk sectors ?
Never underestimate the stupidity of Windows... :)
I really think that the problem is all those hundreds and thousands and
tens of thousands consecutive allocations and deallocations of different
amounts of memory. The memory allocation gets pretty fragmented and Windows
may be unable to handle it efficiently.
It might be the explanation (or not).
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
RAM lying around unused? Blasphemy, I say! You know you could've given it to the
poor and needy (like me).
Margus
Ken wrote:
>
>
> Oh well there is not much I can do about it but it seems it is time to get
> a mother board that will support more that 128 megs of on board ram. I
> have another 96 megs sitting in my desk doing nothing.
>
> --
> Ken Tyler
>
> mailto://tylereng@pacbell.net
> http://home.pacbell.net/tylereng/links.htm
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ken <tyl### [at] pacbellnet> wrote:
>It must be extremely poor memory management if it requires a 200 meg overhead
>to operate in. The numbers are still not adding up even given what you and
Be aware that (as previously stated) each memory allocation (depending on the
compiler) can have a significant overhead. The memory has to be tracked by the
compiler's run time library, and POVRAY also adds an overhead.
FWIW, the overhead for POVWIN is about 20 bytes, plus that of the run-time
library (perhaps another 20 bytes?) Also don't forget that each object can use
multiple memory allocations, depending on what you do with them.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ken wrote in message <379C255E.B4547297@pacbell.net>...
>
>
>This question pertains to the way Pov-Ray for windows reports peak memory.
>
> A scene I rendered this evening had 120k objects. I have 128 megs of
>physical ram memory and about 250 megs of swap space available. The
>128 megs of ram were consumed quickly and the swap file grew to nearly
>220 megs before it finaly finished parsing the file.
Since you are using Windows, at least 70 MB of memory or virtual memory is
in use by Windows. By default, Windows uses 16 MB of memory + 50% of all
memory over 16 MB.
Mark
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mark Wagner <mar### [at] gtenet> wrote:
: Since you are using Windows, at least 70 MB of memory or virtual memory is
: in use by Windows. By default, Windows uses 16 MB of memory + 50% of all
: memory over 16 MB.
Why?
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nieminen Mika wrote in message <379ea269@news.povray.org>...
>Mark Wagner <mar### [at] gtenet> wrote:
>: Since you are using Windows, at least 70 MB of memory or virtual memory
is
>: in use by Windows. By default, Windows uses 16 MB of memory + 50% of all
>: memory over 16 MB.
>
> Why?
Disk cache. Run a big program and watch Windows put the disk cache into
virtual memory!
Mark
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mark Wagner <mar### [at] gtenet> wrote:
: Disk cache. Run a big program and watch Windows put the disk cache into
: virtual memory!
Why the disk cache should be dependant of the RAM size? I don't understand.
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nieminen Mika wrote in message <379f0abd@news.povray.org>...
>Mark Wagner <mar### [at] gtenet> wrote:
>: Disk cache. Run a big program and watch Windows put the disk cache into
>: virtual memory!
>
> Why the disk cache should be dependant of the RAM size? I don't
understand.
Because that's the way Microsoft wrote it.
Mark
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mark Wagner <mar### [at] gtenet> wrote:
:> Why the disk cache should be dependant of the RAM size? I don't
: understand.
: Because that's the way Microsoft wrote it.
I have always understood that the bigger the disk cache, the smaller the
benefits.
If you have 1 MB of disk cache, you will see a big increase in speed.
With 2 MB the speed will increase again, but it will not double. With
4 MB the speed increases a little, but it will be a lot less than 4 times
the speed of 1 MB. The more memory you use for disk caching, the smaller
will the speed/memory-relation be, because you don't get the same benefit
for each MB you add.
This means that the speed achieved with 40 MB will be aproximately the
same as with 42MB. So you wasted 2 MB for nothing.
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nieminen Mika wrote in message <379ff71b@news.povray.org>...
>Mark Wagner <mar### [at] gtenet> wrote:
>:> Why the disk cache should be dependant of the RAM size? I don't
>: understand.
>
>
>: Because that's the way Microsoft wrote it.
>
> I have always understood that the bigger the disk cache, the smaller the
>benefits.
> If you have 1 MB of disk cache, you will see a big increase in speed.
>With 2 MB the speed will increase again, but it will not double. With
>4 MB the speed increases a little, but it will be a lot less than 4 times
>the speed of 1 MB. The more memory you use for disk caching, the smaller
>will the speed/memory-relation be, because you don't get the same benefit
>for each MB you add.
> This means that the speed achieved with 40 MB will be aproximately the
>same as with 42MB. So you wasted 2 MB for nothing.
Try telling Microsoft that. As of Windoze 95, they hadn't learned such
basic engineering concepts as "fail-safe", so that when Win95 crashes on
shutdown (frequently and often), eventually things get messed up so badly
that Windoze must be reinstalled.
Mark
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 28 Jul 1999 04:17:05 -0400, "Mark Wagner"
<mar### [at] gtenet> wrote:
>Disk cache. Run a big program and watch Windows put the disk cache into
>virtual memory!
>
>Mark
There's a $20 shareware proggie for windoze called MemTurbo. A 30-day
trial is available at TUCOWS. It does memory defrags & recovery as
well as controls the min and max cache size. So far I haven't seen any
problems with the trial version, but keep in mind:
a) The first time I ran the program it was able to free up 78 of the
96 MB physical RAM I have (by paging dlls and such to the hdd) when no
programs were running. Now, a typical value is 12-16 MB. Why? I don't
know. Actually, the system behaves better when having 16 MB of free
physical RAM than when having 75 (cause it still needs those dlls and
has to reload them on demand)
b) The cache tuning options are not available in the trial version, so
I can't report on that
c) Cache tuning does not work under NT
Just so that you know :)
Peter Popov
ICQ: 15002700
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Peter Popov wrote in message <37a020bf.17317772@204.213.191.228>...
>There's a $20 shareware proggie for windoze called MemTurbo. A 30-day
>trial is available at TUCOWS. It does memory defrags & recovery as
>well as controls the min and max cache size. So far I haven't seen any
>problems with the trial version, but keep in mind:
>
>a) The first time I ran the program it was able to free up 78 of the
>96 MB physical RAM I have (by paging dlls and such to the hdd) when no
>programs were running. Now, a typical value is 12-16 MB. Why? I don't
>know. Actually, the system behaves better when having 16 MB of free
>physical RAM than when having 75 (cause it still needs those dlls and
>has to reload them on demand)
>
>b) The cache tuning options are not available in the trial version, so
>I can't report on that
I use a postcardware program called "Cacheman" to adjust the disk cache size
on my computer. I have it set up so that no more than 20 MB is used for the
disk cache.
Mark
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
