Mailing-List: contact dev-help@stdcxx.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@stdcxx.apache.org
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1278)
Subject: Re: STDCXX-1056 : numpunct fix
From: Liviu Nicoara <nikkoara@hates.ms>
In-Reply-To: 
 <CALdE9ODV=msOJgWiOVRcTDe1F=sfFQpnMXaZpoexG5QP3mg5+Q@mail.gmail.com>
Date: Thu, 20 Sep 2012 08:07:06 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <346B7FD6-C961-4C0C-91C3-9FBBE442490D@hates.ms>
References: 
 <CALdE9OD1q8y6yo7FhZLwdSA0w5R1Jy0gTFY39GjGbgT+cHYhOQ@mail.gmail.com>
 <505A6877.7090507@hates.ms>
 <CALdE9ODV=msOJgWiOVRcTDe1F=sfFQpnMXaZpoexG5QP3mg5+Q@mail.gmail.com>
To: dev@stdcxx.apache.org

Thanks for the feed-back. Please see below.


On Sep 19, 2012, at 10:02 PM, Stefan Teleman wrote:

> On Wed, Sep 19, 2012 at 8:51 PM, Liviu Nicoara <nikkoara@hates.ms> =
wrote:
>=20
>> I think you are referring to `live' cache objects and the code which
>> specifically adjusts the size of the buffer according to the number =
of
>> `live' locales and/or facets in it. In that respect I would not call =
that
>> eviction because locales and facets with non-zero reference counters =
are
>> never evicted.
>>=20
>> But anyhoo, this is semantics. Bottom line is the locale/facet buffer
>> management code follows a principle of economy.
>=20
> Yes it does. But we have to choose between economy and efficiency. To
> clarify: The overhead of having unused pointers in the cache is
> sizeof(void*) times the number of unused "slots".  This is 2012. Even
> an entry-level Android cell phone comes with 1GB system memory. If we
> want to talk about embedded systems, where memory constraints are more
> stringent than cell phones, then we're not talking about Apache stdcxx
> anymore, or any other open souce of the C++ Standard Library. These
> types of systems use C++ for embedded systems, which is a different
> animal altogether: no exceptions support, no rtti. For example see,
> Green Hills: http://www.ghs.com/ec++.html. And even they have become
> more relaxed about memory constraints. They use BOOST.
>=20
> Bottom line: so what if 16 pointers in this 32 pointer slots cache
> never get used. The maximum amount of "wasted memory" for these 16
> pointers is 128 bytes, on a 64-bit machine with 8-byte sized pointers.
> Can we live with that in 2012, a year when a $500 laptop comes with
> 4GB RAM out of the box? I would pick 128 bytes of allocated but unused
> memory over random and entirely avoidable memory churn any day.


The argument is plausible and fine as far as brainstorming goes.=20

But have you measured the amount of memory consumed by all STDCXX locale =
data loaded in one process? How much absolute time is spent in resizing =
the locale and facet buffers? What is the gain in space and time =
performance with such a change versus without? Just how fragmented the =
heap becomes and is there a performance impact because of it, etc.? IOW, =
before changing the status quo one must show an objective defect, =
produce a body of evidence, including a failing test case for the =
argument.


>=20
> My goal: I would be very happy if any application using Apache stdcxx
> would reach its peak instantiation level of localization (read: max
> number of locales and facets instantiated and cached, for the
> application's particular use case), and would then stabilize at that
> level *without* having to resize and re-sort the cache, *ever*. That
> is a locale cache I can love. I love binary searches on sorted
> containers. Wrecking the container with insertions or deletions, and
> then having to re-sort it again, not so much. Especially when I can't
> figure out why we're doing it in the first place.


And I love minimalistic code, and hate waste at the same time, =
especially in a general purpose library. To each its own.


>=20
>> Hey Stefan, are the above also timing the changes?
>=20
> Nah, I didn't bother with the timings - yet - for a very simple
> reason: in order to use instrumentation, both with SunPro and with
> Intel compilers, optimization of any kind must be disabled. On SunPro
> you have to pass -xkeepframe=3D%all (which disables tail-call
> optimization as well), in addition to passing -xO0 and -g. So the
> timings for these unoptimized experiments would have been completely
> irrelevant.

Well, I think you are the only one around here with access to SPARC =
hardware, your input is very precious in this sense. Also, this is the =
reason for which I kept asking that question earlier: do we have =
currently any failing locale MT test when numpunct does just perfect =
forwarding, with no caching? I.e., changing just _numpunct.h and no =
other source file (as to silence thread analyzers warnings) does any =
locale (or other) MT tests fail? I would greatly appreciate it if you =
could give it a run on your hardware if you don't already know the =
answer.

The discussion has been productive. But I object to the patch as is =
because it goes out of the scope of the original incident. I think this =
patch should only touch the MT defect detected by the failing test =
cases. If you think the other parts you changed are defects you should =
open corresponding issues in JIRA and have them discussed in their =
separate rooms.

Thanks,
Liviu=