incubator-lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Karman <>
Subject Re: [kinosearch-commits] r5736 - trunk/perl/buildlib/KinoSearch
Date Sun, 24 Jan 2010 04:11:04 GMT
Marvin Humphrey wrote on 1/23/10 10:02 PM:

> OK, what about your suggestion of scanning cppsymbols? On my custom-compiled
> vanilla debugging Perl on CentOS 5.2, I see lots of "i386".  So, we could try
> this hack: if it says it's i386, tell it "Haha nice try -- use the i486
> instruction set at least."

that's right along the line I was thinking. Seems like it is a redhat thing.

> I don't know to what extent we can trust $Config{cppsymbols}, though.  The
> output below from my PowerPC Mac Mini seems highly suspect.
> Screw it.  I'm giving up.


> The only time that atomic intrinsics get used right now are when adding new
> classes to VTable_registry, which is a LockFreeRegistry.  That happens
> infrequently enough that performance is not a concern and we can fall back to
> pthread mutexes on systems where atomics are not made available via system
> headers.

yes, that seems right. I noticed the fallback code in there (for Windows?) and 
wondered if KS should be able to detect whether atomics are available and Do the 
Right Thing.

> yogi:perl marvin$ perl -MConfig -le 'print join("\n", split / /, $Config{cppsymbols})'
> __GNUC__=4
> __GNUC_MINOR__=0
> _LP64=1
> __LP64__=1
> __MACH__=1
> __PIC__=1
> __STDC__=1
> __amd64=1
> __amd64__=1
> __x86_64=1
> __x86_64__=1

yes, those don't help at all because I have the exact same set on my Intel mac. :/

Peter Karman  .  .

View raw message