Board index » delphi » Re: Question about FastMM

2005-07-04 08:23:36 AM
delphi49
memory manager.
Brian Moelk
XXXX@XXXXX.COM
www.brainendeavor.com
 

RandomAccess writes:
why automatic selection of an MM would be nice.
--
John Kaster blogs.borland.com/johnk
Features and bugs: qc.borland.com
Get source: cc.borland.com
If it is not here, it is not happening: ec.borland.com
 

them choose a memory manager, then I doubt they will be looking at optimizing
their performance. If they want to improve their performance, then they
will surely have to learn about multi-threading techniques, etc. (especially
with the movement to dual core procs in the future).
So, yes I'd argue that it is their problem.
is usually only in cases where the performance is really horrid. Besides,
I suspect that Delphi Win32 even with a naive memory manager implementation
performs reasonably well against its virtual machine counterparts: Java and
.NET.
Therefore, an ignorant programmer may groan when they don't explicitly pick
the "right" memory manager, but IMO, the experienced programmer will rightfully
groan if Delphi automatically picks the "wrong" memory manager.
Brian Moelk
XXXX@XXXXX.COM
www.brainendeavor.com
 

Certainly RecyclerMM and NexusMM both "work" in the sense they allocate/deallocate
memory; real-world applications use them and function great.
It would be useful to see exactly why those tests show that FastMM is a better
or safer MM than those that do not pass those tests; and ultimately if that
makes any difference whatsoever.
[snip]
Brian Moelk
XXXX@XXXXX.COM
www.brainendeavor.com
 

Brian Moelk <XXXX@XXXXX.COM>writes
<XXXX@XXXXX.COM>
quite correct. I have given in to my nerd status long ago. <g>
--
Everything in this post is mere opinion.
It might be very well formed opinion based
on an uncanny grasp of the facts, but it
remains opinion nevertheless. It may be,
and in fact like most attempts at human
knowledge probably is, quite inaccurate and
incorrect. There is a chance of side
effects, such as misinterpretation,
misrepresentation, and miscommunication.
The opinions expressed in this post may
deviate significantly from your own,
causing you varying degrees of distress.
Some reactions may be severe. Relax, this
is normal, and not a sign that you need to
see your doctor. In the event that a
reaction lasts more than four hours,
consult your therapist.
Posted with Reader3000-BETA 0.9.4.930
 

Brian Moelk <XXXX@XXXXX.COM>writes
<XXXX@XXXXX.COM>
speed too, depending on the app and the end user requirements.
--
Everything in this post is mere opinion.
It might be very well formed opinion based
on an uncanny grasp of the facts, but it
remains opinion nevertheless. It may be,
and in fact like most attempts at human
knowledge probably is, quite inaccurate and
incorrect. There is a chance of side
effects, such as misinterpretation,
misrepresentation, and miscommunication.
The opinions expressed in this post may
deviate significantly from your own,
causing you varying degrees of distress.
Some reactions may be severe. Relax, this
is normal, and not a sign that you need to
see your doctor. In the event that a
reaction lasts more than four hours,
consult your therapist.
Posted with Reader3000-BETA 0.9.4.930
 

Brian Moelk <XXXX@XXXXX.COM>writes
<XXXX@XXXXX.COM>
I actually think it makes a lot more sense for programmers to spend time
acquiring good concurrent programming experience and techniques than .Net or
additional languages (though those are probably more fun for most
programmers). One of the Borlanders recently blogged about trying to make
multi-threading easier for Delphi users, I think it was Danny. that is a good
start, but I think the responsibility really lies on the programmer to learn
this stuff on his own. Writing a multi-threaded app is a lot like writing a
good scalable distributed app, the programmer really needs to think
differently about resource usage and locks and timing than if they were
simply writing a single-threaded app. The language and IDE can not really do
this for them.
--
Everything in this post is mere opinion.
It might be very well formed opinion based
on an uncanny grasp of the facts, but it
remains opinion nevertheless. It may be,
and in fact like most attempts at human
knowledge probably is, quite inaccurate and
incorrect. There is a chance of side
effects, such as misinterpretation,
misrepresentation, and miscommunication.
The opinions expressed in this post may
deviate significantly from your own,
causing you varying degrees of distress.
Some reactions may be severe. Relax, this
is normal, and not a sign that you need to
see your doctor. In the event that a
reaction lasts more than four hours,
consult your therapist.
Posted with Reader3000-BETA 0.9.4.930
 

Brian Moelk writes:
...
works under every condition, so the problematic developer does not have a,
well, problem. it is great to choose between more MMs if you need more speed,
robustness etc, but you need a working default.
...
Rakf
 

Captain Jake writes:
...
(almost) nobody will use it. Make it easy to use, and many will see the
benefit. And that is so true. Why the heck should I define critical sections
etc if there is a so much more elegant solution? Chrome has a very elegant
way to define threads and critical sections. It is simple, it works, and it
does a job the compiler can do much better than I ever could.
Multithreading applications will become more and more state of the art. Make
it easy to build them.
Ralf
 

Brian Moelk writes:
want a fast optimizing compiler. Why wouldn't they also want as fast an
app as possible?
--
John Kaster blogs.borland.com/johnk
Features and bugs: qc.borland.com
Get source: cc.borland.com
If it is not here, it is not happening: ec.borland.com
 

functions are isolated snippets from actual applications.
As for other single-threaded applications, our industrial flow simulator
(palettes, packs, conveyors) can experience 5-50% speedups using an
alternate MM, and funnily enough, most of its allocations are at the
start *before* the calculations begins, gains are from better cache
coherency and from the string temporaries in the logging code (this
application is one of the reason why I started RecyclerMM a few years ago).
Eric
 

an 'Allocated' function, Pierre if you're listening... ;) -- and now has
quite a few features and optimization RecyclerMM never had.
There are some odd situations where latest RecyclerMM versions may come
ahead, but I reckon these are random occurences where f.i. RecyclerMM's
segregation comes closer to your data size than FastMM's, but since both
have a comparable amount of segregation, such an occurence is pure luck.
Eric
 

situation that is completely unrelated to the code that is the root of
the error, making identification and debugging very hard
(non-reproducible error most of the time).
Eric
 

Captain Jake writes:
maybe twice a month. After using a replacement MM, I have not had to do
that in over four months (and still counting...). Whether or not there
was any speed increase is not relevant, but if the app stops responding
due to memory fragmentation and out of memory errors, then one could
argue that the speed increase with the replacement MM is more than 100
fold...
 

On Sun, 3 Jul 2005 18:30:06 -0500, "Captain Jake"
<jake[nospam]@jsnewsreader.com>writes:
FastMM4?
FastMM4 is *one* of the entries in the FastCode competition. RecyclerMM
is another (there are more). Nexus is only used as a reference, as being
one of the most known commercial MM:s.
For the moment, FastMM4 seems to lead the competition in most aspects
(but not all), but there's no guarantee it will be the final 'winner'.
It's even uncertain if it will be possible to select a 'winner'.
Depending on your program's needs, different MM:s may be the 'best'.
--
Anders Isaksson, Sweden
BlockCAD: web.telia.com/~u16122508/proglego.htm
Gallery: web.telia.com/~u16122508/gallery/index.htm