[Quantlib-dev] destructor performance, observables with large observer lists

[Peter C. <pca...@vo...>]

Though probably of marginal importance, I spent some further time in
googling and experiments on the questions below.

I tried to stress the situation with the attached small test code. It has 3
parameters one can play with (the #define's) and two outputs. 

"notFound" counts pointers that are put in a set and not found later on. If
this number is not zero there is a serious problem. However I did not manage
to provoke this on my environment, even with fat and/or many objects
allocated.

"fingerprint" counts the number of subsequently allocated pointers p and q
with not p < q. Different fingerprints (with same parameters) mean that code
relying on the ordering of pointers may show non deterministic or system
dependent behaviour. In fact I can produce different fingerprints with the
same executable on my system e.g. by starting it from a shell (2755), from
the IDE (3142) or double clicking in windows explorer (3193). Not very nice.

There might be real problems with the ordering of pointers on systems
without virtualized memory allocation. Like on dos or win3.x, but this is
not relevant any more for current systems, is it?

Finally the C99 standard actually does explicitly mention pointer
comparision in 6.5.8.

Peter


-----Ursprüngliche Nachricht-----
Von: Peter Caspers [mailto:pca...@vo...] 
Gesendet: Sonntag, 26. Juni 2011 20:28
An: 'Ferdinando Ametrano'
Cc: 'qua...@li...'
Betreff: RE: [Quantlib-dev] destructor performance, observables with large
observer lists

Hi,

the main reason for the map<long,pointer> approach was to avoid using
comparison between pointers, which is to my understanding comparison of
memory addresses.

What if two objects pointed to do not stay in the same memory block for
example? Is the behaviour still well defined then? Even if it works
technically, program execution will probably depend on many things not
covered by the language specifications. It may be hard to get reproducible
results then?

Thank you and regards
Peter


-----Ursprüngliche Nachricht-----
Von: Ferdinando Ametrano [mailto:na...@am...] 
Gesendet: Sonntag, 26. Juni 2011 18:58
An: Plamen Neykov
Cc: qua...@li...; lui...@gm...
Betreff: Re: [Quantlib-dev] destructor performance, observables with large
observer lists

On Sat, Jun 25, 2011 at 5:48 PM, Plamen Neykov
<pla...@re...> wrote:
> wouldn't it be simpler just to use std::set<Observer*> and save you the
trouble with the long id or am I missing something here?

great minds think alike... as a matter of fact in the trunk it has
already been switched to std:set on June 7th :-)

see
http://quantlib.svn.sourceforge.net/viewvc/quantlib?view=revision&revision=1
7788

I was more concerned with possible non-unique elements than
destructor's performance reason, and that's why I would keep it at
std::set instead of having it as template parameter.

Roland could you confirm that the trunk solution is OK for you?

BTW in the current trunk there is a MAJOR performance improvement if
you work in a real time environment with many changing rate quotes
between recalculations: I patched a bug which triggered many useless
notifications

thanks to all for the report and help: it's refreshing to have
contributors really stressing the library.

ciao -- Nando

----------------------------------------------------------------------------
--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
QuantLib-dev mailing list
Qua...@li...
https://lists.sourceforge.net/lists/listinfo/quantlib-dev