VirtualAlloc,GlobalAlloc,HeapAlloc,..what to use in my case,...
Kerem Gümrükcü
i have a application that reads a unknown bunch of
files to a block of memory, handles them and finally
frees the memory. For now, i work with VirtualAlloc,
but i get after processing ~250 Files a GetLastError=8
for any memory request, even i know that memory has
been released with VirtualFree=TRUE. Why is that
the case? The System has 1GB of real physical memory.
Sure i know the limitations of user memory space and
process space. VirtualAlloc will always be called with
MEM_COMMIT and PAGE_READWRITE in my code.
I have to read the complete file, not a piece of it, so
some files are 205 byte others about 20MB. So what
and how can i asure, that my application frees the
allocated memory after ist usage and what are the
differences on processing impact if i use these functions,
better to say: what are the differences between VirtualAlloc,
GlobalAlloc and HeapAlloc? The Application is a single
threaded app and expects a folder path as input, then it
processes the files:
FOR EACH FILE IN FOLDER
IsFileReadable
ReadFileSize
VirtualAlloc
ReadFileContent
DoAnalyzeFileContent
WriteToOwnAppFile
FlushBuffers
VirtualFree
NEXT FILE
ExitApplication
How can i prevent to run into a GetLastError()=8
Subsequent Memory Request fail after a GetLastError=8
Regards
K.
--
-----------------------
Beste Grüsse / Best regards / Votre bien devoue
Kerem Gümrükcü
Microsoft Live Space: http://kerem-g.spaces.live.com/
Latest Open-Source Projects: http://entwicklung.junetz.de
-----------------------
"This reply is provided as is, without warranty express or implied."
Kerem Gümrükcü
i had a look at its resource uttilization/usage with process
explorer and it grows exponentially expecially its "Virtual Size"
for Virtual Memory, sure for VirtualAlloc and its CPU Usage.
At a certail level it slows down the complete system and os starts
to work with the pagefile until i kill or stop the process,...
Something is wrong here, I think i should not use VirtualAlloc
or find a way to 100% give back the allocated memory and
then reallocate new memory. How can i force my application
to use real physical memory instead virtual? Dow, this belongs
to the OS and its internals, i know,...
I found this:
[Comparing Memory Allocation Methods]
http://msdn2.microsoft.com/en-us/library/aa366533.aspx
which makey my decision go HeapAlloc, because of the page granularity,...
Regards
K.
--
-----------------------
Beste Grüsse / Best regards / Votre bien devoue
Kerem Gümrükcü
Microsoft Live Space: http://kerem-g.spaces.live.com/
Latest Open-Source Projects: http://entwicklung.junetz.de
-----------------------
"This reply is provided as is, without warranty express or implied."
"Kerem Gümrükcü" <kare...@hotmail.com> schrieb im Newsbeitrag
news:ObQOrcL...@TK2MSFTNGP06.phx.gbl...
Alexander Grigoriev
"Kerem Gümrükcü" <kare...@hotmail.com> wrote in message
news:ObQOrcL...@TK2MSFTNGP06.phx.gbl...
Kerem Gümrükcü
nah,....i am such an moron, you where right. I have several vrapper
functions
arround the VirtualAlloc and VirtualFree and i was passing accidentally
a MEM_DECOMMIT to a VirtualFree, not a MEM_RELEASE and also
not a zero as second parameter. This was not clear because of my own flags
and complex wrappers,....dow,...
God idea, good work,...bal'schoje sspassiba!
Alex Blekhman
> I have several vrapper functions arround the VirtualAlloc and
> VirtualFree and i was passing accidentally a MEM_DECOMMIT to a
> VirtualFree, not a MEM_RELEASE and also not a zero as second
> parameter. This was not clear because of my own flags and
> complex wrappers,....dow,...
The real question here is why do you need `VirtualAlloc' at all?
You always call it with `MEM_COMMIT' and `PAGE_READWRITE' flags
making it eventually indistinguishable form regular `operator new'
or `malloc'. Actually you're making it worse since you miss all
optimizations that CRT may enable (like Low Fragmentation Heap,
for example).
I suggest you at least to try your code with regular `new' and
`delete'. Also, if you want to avoid buffer allocations
altogether, then you can use memory mapping to read the files.
Alex
Alexander Grigoriev
"Alex Blekhman" <tkfx....@yahoo.com> wrote in message
news:u%23B7IxPg...@TK2MSFTNGP06.phx.gbl...
Kerem Gümrükcü
>The real question here is why do you need `VirtualAlloc' at all?
Why not and i also want the MEM_WRITE_WATCH Option
for some special purpose. I must watch some special areas of
the memory. There is a bit more in going on my application, nit
just read and write some files and streams.
>You always call it with `MEM_COMMIT' and `PAGE_READWRITE' flags making it
>eventually indistinguishable form regular `operator new' or `malloc'.
the C++ "new" Operator is no option for me, because it is a plain
C Application and i dont want to mix it up with C++ heap memory
stuff.
>Actually you're making it worse since you miss all optimizations that CRT
>may enable (like Low Fragmentation Heap, for example).
I can still use HeapCompact(...) if i need to...
>I suggest you at least to try your code with regular `new' and `delete'.
No C++,...
Thanks,...
Regards
K.
--
-----------------------
Beste Grüsse / Best regards / Votre bien devoue
Kerem Gümrükcü
Microsoft Live Space: http://kerem-g.spaces.live.com/
Latest Open-Source Projects: http://entwicklung.junetz.de
-----------------------
"This reply is provided as is, without warranty express or implied."
"Alex Blekhman" <tkfx....@yahoo.com> schrieb im Newsbeitrag
news:u%23B7IxPg...@TK2MSFTNGP06.phx.gbl...
Nathan Mates
Kerem Gümrükcü <kare...@hotmail.com> wrote:
>>You always call it with `MEM_COMMIT' and `PAGE_READWRITE' flags making it
>>eventually indistinguishable form regular `operator new' or `malloc'.
>the C++ "new" Operator is no option for me, because it is a plain
>C Application and i dont want to mix it up with C++ heap memory
>stuff.
new and malloc both use the same heap, provided by the C Runtime
library, which is used by C and/or C++ code. They can coexist just
fine, no matter which language requested the memory, and nothing will
be 'mixed up.' Plus, your code will be far more portable to other
(i.e. non-Win32) systems.
Nathan Mates
--
<*> Nathan Mates - personal webpage http://www.visi.com/~nathan/
# Programmer at Pandemic Studios -- http://www.pandemicstudios.com/
# NOT speaking for Pandemic Studios. "Care not what the neighbors
# think. What are the facts, and to how many decimal places?" -R.A. Heinlein
Joseph M. Newcomer
use; it is used in rare situations (I've used it twice in over 15 years of Win32
programming).
There is a horrid fascination with people reporting the amount of physical memory on their
machines; this is almost totally irrelevant to the question of running out of memory,
because you are not running out of physical memory, you are running out of virtual memory.
Use 'malloc' if you are programming in C or 'new' if you are programming in C++. I would
not consider VirtualAlloc, GlobalAlloc or HeapAlloc for any of these situations.
For that matter, one of the fastest ways to do this would be to scan the directory, find
the largest file, allocate one buffer of that size, and use it for all the other files.
Each time you open a file, you double-check that the memory you allocated is still large
enough (the file might have grown, but once you open it exclusive, it isn't going to get
any larger). If it isn't, you reallocate at that point, otherwise you retain your
allocation. This avoids issues of memory fragmentation (if you're not sure what this
means, read my essay on storage allocation on my MVP Tips site)
joe
Joseph M. Newcomer [MVP]
email: newc...@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
Joseph M. Newcomer
the first place?
Why use HeapAlloc when 'new' or 'malloc' work just fine?
From the essay
====Although the GlobalAlloc, LocalAlloc, and HeapAlloc functions ultimately allocate
====memory from the same heap, each provides a slightly different set of functionality.
====For example,
====HeapAlloc can be instructed to raise an exception if memory could not be
====allocated, a capability not available with LocalAlloc.
****
Nobody cares about raising exceptions, because these are SEH exceptions which don't play
well with MFC, so this feature is irrelevant.
HeapAlloc is used if you have to allocate storage in DllMain, and almost nowhere else in
user-level code (the low-level allocators use it)
****
====LocalAlloc supports allocation
====of handles which permit the underlying memory to be moved by a reallocation without
====changing the handle value, a capability not available with HeapAlloc.
****
Since there is no reallocation mechanism worth using, the use of LocalAlloc is essentially
irrelevant
*****
====The VirtualAlloc function allows you to specify additional options for memory
====allocation. However, its allocations use a page granularity, so using VirtualAlloc can
====result in higher memory usage.
****
Largely irrelevant; the concept of page granularity does not even enter the discussion at
the level you are working, because losing a fraction of a page on a 20MB file is such a
tiny percentage (average: 0.01%, that's right, %, or 0.0001) that there is no reason to
ever consider it as an issue. For a 205byte file, yes, if you were going to keep that
storage for any duration, but you don't, you free it immediately
*****
====The malloc function has the disadvantage of being run-time dependent.
*****
But if you're writing in MFC, you don't care in the slightest about this. It uses the
same runtime as the rest of your program. It would be an unaesthetic choice, but not an
incorrect one.
*****
====The new operator has the disadvantage of being compiler dependent and
====language dependent.
*****
And what is the point? You're writing MFC code in C++, so it does't matter if it is
language dependent!
*****
====The CoTaskMemAlloc function has the advantage of working well in either C, C++, or
====Visual Basic. It is also the only way to share memory in a COM-based application,
====since MIDL uses CoTaskMemAlloc and CoTaskMemFree to marshal memory.
*****
But you're not using COM, so this is inoperative
It sounds to me like you are badly fragmenting storage. I would avoid this by doing as I
outlined earlier: one allocation of max size with a fallback strategy of a realloc if
necessary, but only if necessary.
joe
****
On Sat, 8 Mar 2008 02:13:22 +0100, "Kerem Gümrükcü" <kare...@hotmail.com> wrote:
>Hi,
>
>i had a look at its resource uttilization/usage with process
>explorer and it grows exponentially expecially its "Virtual Size"
>for Virtual Memory, sure for VirtualAlloc and its CPU Usage.
>At a certail level it slows down the complete system and os starts
>to work with the pagefile until i kill or stop the process,...
>
>Something is wrong here, I think i should not use VirtualAlloc
>or find a way to 100% give back the allocated memory and
>then reallocate new memory. How can i force my application
>to use real physical memory instead virtual? Dow, this belongs
>to the OS and its internals, i know,...
>
>I found this:
>[Comparing Memory Allocation Methods]
>http://msdn2.microsoft.com/en-us/library/aa366533.aspx
>
>which makey my decision go HeapAlloc, because of the page granularity,...
>
>
>Regards
>
>K.
Joseph M. Newcomer
On Sat, 8 Mar 2008 17:20:13 +0100, "Kerem Gümrükcü" <kare...@hotmail.com> wrote:
>Hi Alex,
>
>>The real question here is why do you need `VirtualAlloc' at all?
>Why not and i also want the MEM_WRITE_WATCH Option
>for some special purpose. I must watch some special areas of
>the memory. There is a bit more in going on my application, nit
>just read and write some files and streams.
****
I keep being amazed by people who fail to define the entire problem, and want a solution
to some part of it.
OK, you've justifed VirtualAlloc. You could have done this at the start.
*****
>
>
>>You always call it with `MEM_COMMIT' and `PAGE_READWRITE' flags making it
>>eventually indistinguishable form regular `operator new' or `malloc'.
>
>the C++ "new" Operator is no option for me, because it is a plain
>C Application and i dont want to mix it up with C++ heap memory
>stuff.
>
>>Actually you're making it worse since you miss all optimizations that CRT
>>may enable (like Low Fragmentation Heap, for example).
>
>I can still use HeapCompact(...) if i need to...
>
>>I suggest you at least to try your code with regular `new' and `delete'.
>
>No C++,...
>
>Thanks,...
>
>Regards
>
>K.
Kerem Gümrükcü
>Why use VirtualAlloc at all? Doesn't make much sense to me to see this
>low-level call in
>use; it is used in rare situations (I've used it twice in over 15 years of
>Win32
>programming).
I think i posted the reason, because i need to keep track of several regions
of the
memory to get signaled on change/read/write/access...
>There is a horrid fascination with people reporting the amount of physical
>memory on their
>machines; this is almost totally irrelevant to the question of running out
>of memory,
>because you are not running out of physical memory, you are running out of
>virtual memory.
I think i said that i know what realy physical memory and the virtual adress
space means
and thas why i said my application sizes tremendously its "virtual" memory.
I can have a
application that requests 500MB Ram on a system with 256 MB real physical
ram, it
would work, but my system paging file would also "work",...
>Use 'malloc' if you are programming in C or 'new' if you are programming in
>C++.
>I would not consider VirtualAlloc, GlobalAlloc or HeapAlloc for any of
>these situations.
Then let me ask you: Why are these functions available to the users, if i
should not use them?
VirtualAlloc is interessting to me, because of its "notification"
features,...
>For that matter, one of the fastest ways to do this would be to scan the
>directory, find
>the largest file, allocate one buffer of that size, and use it for all the
>other file
>Each time you open a file, you double-check that the memory you allocated
>is still large
>enough (the file might have grown, but once you open it exclusive, it isn't
>going to get
>any larger). If it isn't, you reallocate at that point, otherwise you
>retain your
>allocation. This avoids issues of memory fragmentation (if you're not sure
>what this
>means, read my essay on storage allocation on my MVP Tips site)
This is a really good idea, at least i would not make my application
alloc/free
free like hell,...
Kerem Gümrükcü
>new and malloc both use the same heap, provided by the C Runtime
>library, which is used by C and/or C++ code. They can coexist just
>fine, no matter which language requested the memory, and nothing will
>be 'mixed up.' Plus, your code will be far more portable to other
>(i.e. non-Win32) systems.
Thank you i know that, but i hold my code strictly in C
and dont want to mix it with c++ language features. Yes,
in general there is no difference using them, but this time
its a language thing,...
Kerem Gümrükcü
>I keep being amazed by people who fail to define the entire
>problem, and want a solution to some part of it.
I dont understand,...if i could define the entire problem, be sure
that i had solved it by my own. Thats why i asked this here, because
it was not clear to me, why my mem usage decreased, even when i
deallocated it. As told before, i have several wrappers around the
VirtualAlloc/HeapAlloc and it was a implementation mistake i made.
I passed a wrong parameter to the VirtualFree, but i was not aware
of it, because it was no longer the original call to VirtualAlloc, it was
wrapped by my function call,...
>OK, you've justifed VirtualAlloc. You could have done this at the start.
Was this necessary,...the original question was: Why does my application
consume even more memory and why does it seem that it uses more
and more memory, even for the case i free it and ensure clean
allocation/freeing, even by securing things with SEH and Syncronization.
Ok, i didnt tell SEH and Sync, but it was not necessary. Alexander pointed
at the VirtualFree and yes, it was the right place to look. The wrappers
look like "LPVOID vi_virtual_alloc(SIZE_T)" and vi_virtual_free(LPVOID).
The Internals of the wrappers include some extra operation on the memory
before it will be freed or returned to the caller. I passed a wrong
parameter
to VF, and thats because i overloaded a function and accidentally used its
old parameter from the base function....
Everything is now fine....
Thanks!
Nathan Mates
Kerem Gümrükcü <kare...@hotmail.com> wrote:
>>new and malloc both use the same heap, provided by the C Runtime
>>library, which is used by C and/or C++ code. They can coexist just
>>fine, no matter which language requested the memory, and nothing will
>>be 'mixed up.' Plus, your code will be far more portable to other
>>(i.e. non-Win32) systems.
>Thank you i know that, but i hold my code strictly in C
>and dont want to mix it with c++ language features. Yes,
>in general there is no difference using them, but this time
>its a language thing,...
As I pointed out above, malloc is a perfectly reasonable function
to use. It's 100% C, no C++. Go read your K&R if you don't believe
me. Plus, malloc is portable to other systems just fine. As long
as you balance your malloc/free calls, then your app should behave
fine.
Joseph M. Newcomer
On Sun, 9 Mar 2008 03:47:53 +0100, "Kerem Gümrükcü" <kare...@hotmail.com> wrote:
>Hi Joseph,
>
>>Why use VirtualAlloc at all? Doesn't make much sense to me to see this
>>low-level call in
>>use; it is used in rare situations (I've used it twice in over 15 years of
>>Win32
>>programming).
>
>I think i posted the reason, because i need to keep track of several regions
>of the
>memory to get signaled on change/read/write/access...
****
Yes, I saw that in a later part of a thread. But you should have said this up front to
make your use of VirtualAlloc make sense
****
>
>>There is a horrid fascination with people reporting the amount of physical
>>memory on their
>>machines; this is almost totally irrelevant to the question of running out
>>of memory,
>>because you are not running out of physical memory, you are running out of
>>virtual memory.
>
>I think i said that i know what realy physical memory and the virtual adress
>space means
>and thas why i said my application sizes tremendously its "virtual" memory.
>I can have a
>application that requests 500MB Ram on a system with 256 MB real physical
>ram, it
>would work, but my system paging file would also "work",...
****
So why should anyone care how much physical memory you have on your machine? It has
nothing to do with answering the question or causing the problem
****
>
>
>>Use 'malloc' if you are programming in C or 'new' if you are programming in
>>C++.
>>I would not consider VirtualAlloc, GlobalAlloc or HeapAlloc for any of
>>these situations.
>
>Then let me ask you: Why are these functions available to the users, if i
>should not use them?
****
Just because an API exists does not say that its use represents best practice, good
practive, or even acceptable practice. I once had a programmer insist that VirtualAlloc
was the fastest way to allocate memory! (He apparently could not understand that a kernel
call is several orders of magnitude worse peformance than a subroutine call). In general,
and without any other justification, VirtualAlloc is not a sensible way to allocate
memory.
*****
>VirtualAlloc is interessting to me, because of its "notification"
>features,...
****
Yes, and that is not the general case. That is a very specific case, for which the API is
useful. But since you did not state this requirement as part of your original problem
statement, the assumption is that you chose it randomly because it looked like it might
allocate memory in a useful way.
In many of my posts, I will add the qualification "except in rare and exotic
circumstances". The need to detect data changes falls deeply into the rare-and-exotic
category.
****
>
>>For that matter, one of the fastest ways to do this would be to scan the
>>directory, find
>>the largest file, allocate one buffer of that size, and use it for all the
>>other file
>>Each time you open a file, you double-check that the memory you allocated
>>is still large
>>enough (the file might have grown, but once you open it exclusive, it isn't
>>going to get
>>any larger). If it isn't, you reallocate at that point, otherwise you
>>retain your
>>allocation. This avoids issues of memory fragmentation (if you're not sure
>>what this
>>means, read my essay on storage allocation on my MVP Tips site)
>
>This is a really good idea, at least i would not make my application
>alloc/free
>free like hell,...
****
Some years ago, I wrote what was then, and might still be, the world's fastest storage
allocator (it was so fast that we considered compiling the equivalent of 'malloc' inline
for most cases [but it was in a single-threaded environment]). A few weeks after its
release, one product group came to me and said that my allocator was the cause of all
their performance problems, which I did not believe. They brought me the performance
output, which showed a massive spike at the storage allocator. So I reached in with the
debugger and set a flag bit in a configuration word (used in the debug version, which they
were running). Upon completion, we saw that the reason the storage allocator was a
performance bottleneck was that it was called over 4,000,000 times. It was a situation
much like yours, where a block of storage was allocated each time through a loop. The
solution was to declare a stack variable of size N, and each time through the loop, see if
a block >N was needed. If so, a block of max(2*current_size, computed_new_limit) was
allocated, and left in place until *it* became too small, in which case the same algorithm
was used to allocate a new block. The result was that from that loop the allocator might
be called four (4) times, in the worst example we ran (and it took only one reallocation
per loop in the worst case, 0 in the typical case). The allocator disappeared as a
performance consideration.
joe
****
Joseph M. Newcomer
you. You did not justify the use of VirtualAlloc, so it was not clear why you needed some
complex method that was no more powerful than malloc or new, given the stated
requirements.
Had you stated why you were using VirtualAlloc and shown the code, the whole thing would
have been simpler to answer.
joe
Kerem Gümrükcü
>As I pointed out above, malloc is a perfectly reasonable function
>to use. It's 100% C, no C++. Go read your K&R if you don't believe
>me. Plus, malloc is portable to other systems just fine. As long
>as you balance your malloc/free calls, then your app should behave
>fine.
its not an option for me and my application is not portable to other
systems. Its ok to use it, but not in my case,...
Anyway thanks,...
Regards
K.
--
-----------------------
Beste Grüsse / Best regards / Votre bien devoue
Kerem Gümrükcü
Microsoft Live Space: http://kerem-g.spaces.live.com/
Latest Open-Source Projects: http://entwicklung.junetz.de
-----------------------
"This reply is provided as is, without warranty express or implied."
"Nathan Mates" <nat...@visi.com> schrieb im Newsbeitrag
news:13t6q4p...@corp.supernews.com...
Kerem Gümrükcü
>Had you shown the actual code, instead of a vague handwave,
>we might have spotted it for
The overall code is too large to paste here and i even have a lot
of inline assembly but you are right, i had to past the code here.
But its fine now,....
>You did not justify the use of VirtualAlloc,
>so it was not clear why you needed some
Again, i didnt thought it was necessary, because the question was
"why" my system was consuming heavy memory and increasing its
memory usage, but ok,...
>Had you stated why you were using VirtualAlloc and shown the code, the
>whole thing would
>have been simpler to answer.
I found the problem after the Tip from Alexander, so it was solved very
early, i think even after the third posting/first reply. So i dont think
that
we must continue here, but thanks for your effort. its really solved and
ok now,...
Kerem Gümrükcü
thanks to everybody and all answers,...
It has been solved successfully and i have learned
a lot of things again....
Joseph M. Newcomer
On Sun, 9 Mar 2008 12:55:51 +0100, "Kerem Gümrükcü" <kare...@hotmail.com> wrote:
>Hi Joe,
>
>>Had you shown the actual code, instead of a vague handwave,
>>we might have spotted it for
>
>The overall code is too large to paste here and i even have a lot
>of inline assembly but you are right, i had to past the code here.
>But its fine now,....
>
>>You did not justify the use of VirtualAlloc,
>>so it was not clear why you needed some
>
>Again, i didnt thought it was necessary, because the question was
>"why" my system was consuming heavy memory and increasing its
>memory usage, but ok,...
****
But the answer as to "why" would have been obvious had you posted your VirtualFree
code...you showed a 'correct' handwave, but your code did not implement what your
statement of your solution was. So, by looking at your stated solution, nothing appeared
to be wrong.
Inline assembly code? Scary...
****
>
>>Had you stated why you were using VirtualAlloc and shown the code, the
>>whole thing would
>>have been simpler to answer.
>
>I found the problem after the Tip from Alexander, so it was solved very
>early, i think even after the third posting/first reply. So i dont think
>that
>we must continue here, but thanks for your effort. its really solved and
>ok now,...
>
>Regards
>
>K.
Kerem Gümrükcü
>Inline assembly code? Scary...
I wont say scarry,..i rather would say a "necessity" for some
operations that must be performed as fast as possible. You as
a professional and very experienced developer should know
what i am talking about, especially in the case of mathematical
calculations and algorithms, there is nothing that can beat fast
direct cpu uperations with dedicated instructions and fast register
access. You can strip down your code and compact it as much
as possible and write your own prolog and epilog and create
your own operative mechanism. But you are right many many
developers still "underrate" the power of assembly in high level
languages and most of them still think, that assembly is difficult
and something like black magic. A friend of mine, a pro
.NET Developer always thinks that Assembly is dead. Thats
"scary" to me. I also do .NET development, and very often,
but there is nothing that can beat assembly and C/C++. Operating
directly on hardware is the closest level to speed and fills the
gap of the sometimes missed speed or missing features of
runtime libraries. But on the other hand, if you are not used
to assembly you can slow down someting that can be much
faster with right high level code and good compiler optimization.
This is the case if someone does not have a good knowledge of
low level coding and has a lot of "intermediate" assembly instructions
which cann e.g. solved with a special instruction in one row and
cycle insted of throwing out a lot of moves, pushes, jumps and
aritmethic operations. I always high recommend everybody to learn
at least the basics of assembly language. Even if someone does
not use asembly this makes you understand how function calls,
memory operations and "natve debigging" works. I very good
book on this was a book i read years ago from Joh Robbins,
named "Debugging Windows". Highly recommended! I dont
know whether this book is still up to date (new releases?)
but even for today it is a very good book for learning how
basic debugging works...
Kerem Gümrükcü
and go,...
Joseph M. Newcomer
and worked for a company that produced them) is that nearly all the time the compiler can
produce better code than a programmer writing assembly code.
What is scary is that you are creating code which is expensive to write, expensive to
debug, and expensive to maintain, without a quantitative justification for the performance
improvement.
I have a friend who didn't like the code he was getting, so he wrote a program that
transformed his computation into a collection of grossly-ugly goto-style code. This code
ran substantially faster, but it had the advantage that his algorithms were always written
in C, then compiled into C that the (rather weak) optimizing compiler he had available to
him would compile into more efficient code. Key here was that he never actually would
write code as ugly as his tool produced, but it didn't matter. He didn't write that code.
And his tool was generally useful for a variety of problems, not just one particular piece
of code (all involved repetitive array computations). His machine had no cache, so he
didn't worry about cache hits. He later extended it to do function inlining (his C
compiler had no __inline directive) and actually did get an order of magnitude performance
improvement.
Note that the only way to measure code performance is in the release version; no debug
code can ever be used as a benchmark or a criterion for determining computational cost.
Use #pragma to turn on every possible optimization in the code (note that some
optimizations are not "generally" safe, such as antialiasing, but in the context of, say,
a mathematical computation on arrays will buy a lot). When possible, use inlines.
Optimizations such as strength reduction, loop unrollilng, alpha motion, omega motion, and
common subexpression elimination can often be done more efficiently by writing in C/C++.
I have been using optimizing compilers since 1969, and the number of times I have found
myself able to beat the compiler is vanishingly small. To me, assembly code is easy to
read, but not cost-effective to write.
Example: we had to do an FFT of integer data. I converted the data from integer to double
in a copy of the array, passed it to the FFT subroutine, took the converted array,
converted it back to integers for plotting, and we could not detect the impact of this on
the overall performance; it appeared to operating in "real time". The major overheads of
the operation were the new/delete of the double array and the new/delete of the int array,
and in a real-time system they were still unnoticeable. The major computation was in the
FFT algorithm, a proprietary algorithm developed in MATLAB by a numerical methods expert;
MATLAB emitted C code to do the computaiton.
We carefully examined the compiler-generated code in the FFT subroutine. Two
assembly-code experts could not come up with anything significantly faster...we might have
managed to get 3%-5% out of it at best, not worth the effort.
Writing assembly code can, under extreme conditions, get you as much as a factor of 2
performance performance improvement. Changing your code to maximize L1 and L2 cache hits
can buy you a factor of 10 to 20, while remaining in C/C++. If you really care about
performance, data access organization is vastly more important than the cost of an
instruction in an inner loop. So if you are concentrating on instructions, you are
missing the high-payoff optimizations which are not code optimizations, but architecture
optimizations (you change your algorithm).
Note that if you are working on large data arrays, paging can become the dominant problem.
A page fault costs you about six orders of magnitude performance. All the assembly code
in the world will not "reimburse" you for a single page fault.
Some years ago, I wrote the world's fastest storage allocator, and to do this I did NOT
consider assembly code, but used a high-level language comparable to Ada. It had four
levels of abstraction between the user and the actual memory blocks. A good optimizing
compiler, with strong hints from __inline directives, can reduce three levels of
abstraction to half an instruction. The equivalent of malloc, had we actually had an
__inline capability (which was going to be in a future compiler release) would have been
__inline PVOID allocate(int n) {
if(n > limit)
general_allocator(n);
else
{
PVOID result = head[
(n + quantum-1)/quantum];
if(result == NULL)
return general_allocator(n);
else
{
head = head->next;
return result;
}
}
which in our compiler, had we done the inlining, would have generated the equivalent of
mov eax, head[7]
test eax
jne $1
push 28
call general_allocator
jmp $2
$1: mov ebx, DWORD PTR[eax]
mov head[7], ebx
$2:
Note that limit was a compile-time constant and n almost always was a compile-time
constant. It would have taken 5 instructions to allocate storage in most cases, which
means it would take, in a modern machine, <10ns to do a storage allocation (single thread
assumption here) [it took us 5us, because n that machine, it was one instruction/us,
2000-3000 times slower than a modern machine]. We didn't need to write it in assembler to
get that performance. (As it turned out, because of parameter passing, it took us 4 extra
instructions to call, and because at that point the value n was no longer a CTC, it took 3
extra instructions to implement the if-test, so inlining would have bought nearly a
factor-of-2 performance increase in allocation with zero effort on our part. It was not a
high priority because the allocator accounted for < 1% of the total execution time in an
allocation-heavy application where we would allocate and free tends of thousands of
objects).
I've written hundreds of thousands of lines of assembly code in my career; possibly as
many as half a million. For cost-effectiveness, nothing beats a good optimizing compiler.
For performance, with very rare exceptions, nothing beats a good optimizing compiler.
If my goal was to write the fastest possible inner loop for a mathematical computation, I
would be spending my time worrying about cache hits first. Maximize cache hits. Hmmm.
Now that I stop to think about it, my CPUID Explorer was done because I had to optimize
some numeric code based on cache sizes, and needed to know the cache architecture...and
yes, you can get an order of magnitude performance improvement. Without writing a single
line of assembly code, I got better than a factor of 10 improvement.
Assembly code is a last resort. The last three times I used it, I used it because I
needed to execute very low-level code, such as CPUID and RDTSC, not supported in the C
language.
Think algorithms, not code. Think architecture, not instructions.
joe
Alexander Grigoriev
"Joseph M. Newcomer" <newc...@flounder.com> wrote in message
news:vcg8t313hoeo4q5e3...@4ax.com...
>
> Assembly code is a last resort. The last three times I used it, I used it
> because I
> needed to execute very low-level code, such as CPUID and RDTSC, not
> supported in the C
> language.
>
And now there are __rdtsc and __cpuid intrinsics.
Joseph M. Newcomer
joe
Ben Voigt [C++ MVP]
> See below...
> On Sun, 9 Mar 2008 03:47:53 +0100, "Kerem Gümrükcü"
> <kare...@hotmail.com> wrote:
>
>> Hi Joseph,
>>
>>> Why use VirtualAlloc at all? Doesn't make much sense to me to see
>>> this low-level call in
>>> use; it is used in rare situations (I've used it twice in over 15
>>> years of Win32
>>> programming).
>>
>> I think i posted the reason, because i need to keep track of several
>> regions of the
>> memory to get signaled on change/read/write/access...
> ****
> Yes, I saw that in a later part of a thread. But you should have
> said this up front to make your use of VirtualAlloc make sense
> ****
I would go further and say that, based on the initial statement that the OP
was considering HeapAlloc and LocalAlloc as well as VirtualAlloc, that there
was a strong implied claim that the unique features of VirtualAlloc weren't
needed.
Kerem Gümrükcü
>I would go further and say that, based on the initial statement that the OP
>was considering HeapAlloc and LocalAlloc as well as VirtualAlloc, that
>there was a strong implied claim that the unique features of VirtualAlloc
>weren't needed.
Why you say that? I just asked what the differences are, except the
Information in the MSDN Library. How can you say that i dont need
this feature, without knowing what my code is doing?
>I would go further,...
You go "too" far Ben,...
>was considering HeapAlloc and LocalAlloc as well as VirtualAlloc
Yes i did at first, but this feature made my decision stronger, otherwhise
i had to poll the information from the memory by my own with a timer or
some sort of Kernel Objects like Signals, etc,...
But everything is just fine now,...thanks for the replies!
Regards
K.
--
-----------------------
Beste Grüsse / Best regards / Votre bien devoue
Kerem Gümrükcü
Microsoft Live Space: http://kerem-g.spaces.live.com/
Latest Open-Source Projects: http://entwicklung.junetz.de
-----------------------
"This reply is provided as is, without warranty express or implied."
"Ben Voigt [C++ MVP]" <r...@nospam.nospam> schrieb im Newsbeitrag
news:%23zbraxr...@TK2MSFTNGP06.phx.gbl...
Ben Voigt [C++ MVP]
> Hi Ben,
>
>> I would go further and say that, based on the initial statement that
>> the OP was considering HeapAlloc and LocalAlloc as well as
>> VirtualAlloc, that there was a strong implied claim that the unique
>> features of VirtualAlloc weren't needed.
>
> Why you say that? I just asked what the differences are, except the
> Information in the MSDN Library. How can you say that i dont need
> this feature, without knowing what my code is doing?
I can't, but that's why I didn't. *You* said, in several different messages
in this thread, that HeapAlloc was a viable alternative.
Kerem Gümrükcü
yes *I did*, but you shouldn't come to the conlusion, that i
did not know what i am doing, so at least thats what it sounds
to me, when you think , "that there was a strong implied claim
that the uniquevfeatures of VirtualAlloc weren't needed". If i did
not had the chance to use the notification feature, i had to poll the
memory or had to use another signaling mechanism to check for
Change events. There was also the Question "what" benefits the
VA has against the HA, except the features described in the MSDN,
whether someone has experinence on the usage there. But its all solved
now and thanks for your answers on my topic.
Regards
K.
--
-----------------------
Beste Grüsse / Best regards / Votre bien devoue
Kerem Gümrükcü
Microsoft Live Space: http://kerem-g.spaces.live.com/
Latest Open-Source Projects: http://entwicklung.junetz.de
-----------------------
"This reply is provided as is, without warranty express or implied."
"Ben Voigt [C++ MVP]" <r...@nospam.nospam> schrieb im Newsbeitrag
news:ebdtw44g...@TK2MSFTNGP02.phx.gbl...