On Dec 25, 2010, at 5:17 PM, Per Øyvind Karlsen wrote:
> 2010/12/25 Jeff Johnson <[email protected]>:
>> Ick.
>>
>> WITH_VALGRIND is a compile, not a run-time, option,
> Which was semi-broken due to mixup between usage of #ifdef
> WITH_VALGRIND & #ifdef VALGRIND and also a missing ';'.. :p
> I haven't changed it being a compile option though, only the means to
> detect whether actually running under valgrind when compiled with
> WITH_VALGRIND,
> this so that the jlu32*() functions will run the faster code when not
> running under valgrind, while running the valgrind friendly code only
> when running under valgrind.
I missed that RUNNING_WITH_VALGRIND was a VALGRIND annotation.
Still it doesn't belong in lib/rpmrc.c, just do in rpmio/lookup3.c:
#if defined(WITH_VALGRIND)
static in jlu_valgrind = RUNNING_WITH_VALGRIND;
#endif
to keep it KISS.
> This is quite sensible behaviour IMO at least. :)
All depends on POV. lookup3.c used to diff against
the distributed version with almost no pain. Now there's
a maintenance task associated.
ANd you have exactly the same problem wherever lookup3.c is
used, e.g. its in popt too.
All of which starts to make it pointless obsession. Almost
noone uses valgrind, why bother making it a run-time option?
But yes, as functionality matures, its more sensible to have
run-rime, not compile-time, options. True for all sorts
of cunctionality, including dlopen(3). But for valgrind
diagnostics I just cannot see how the cost justifies the benefit.
>>
>> And I haven't a clue why there's a change needed
>> for lib/rpmc.c. Presumably its for --showrc ...
>> ... do you really think anyone cares?
> No, it's for detecting whether running under valgrind, I figured this possibly
> being the most appropriate place to do so to detect as early as possible
> if of use as early as possible, doing it one time only.
rpmio/lookup.c is the appropriate place. Its the only piece
of code that (currently) wants/needs to test RUNNING_WITH_VALGRIND.
A static int (if permitted) will be one time only. Otherwise
roll a one-shot test, that ain't hard at all.
>>
>> And there's already a means to just set a macro,
>> where the display with --showrc Just Happens.
> Not trying to set a macro nor messing with --showrc display.
Then why in lib/rpmrc.c, which is largely just
baggage?
BTW, you might just try to add
#pragma parallel for
(there's more than 1-line needed in most of the loops)
and get up to speed on OpenMP. The loops in rpmbf
are quite simple.
What would be interesting is the measurement ... I don't expect
any significant gain in rpmbf.c per se. But you gotta start
with simple before moving to more complex loops.
73 de Jeff______________________________________________________________________
RPM Package Manager http://rpm5.org
Developer Communication List [email protected]
