Re: [Lucy] Re: [KinoSearch] [kinosearch-commits] r5736 - trunk/perl/buildlib/KinoSearch

[Peter Karman <pe...@peknet.com>]

Marvin Humphrey wrote on 1/23/10 8:56 PM:
> On Sat, Jan 23, 2010 at 08:21:38PM -0600, Peter Karman wrote:
>> perhaps checking $Config{'cppsymbols'} in Build.pm would be appropriate, 
>> for conditionally setting -march ?
> 
> I put in a check for $Config{ptrsize} with commit r5739, assigning -march only
> on 32-bit systems.  Does leaving the flag off work for 64-bit systems?

yes, leaving the flag off is fine. The only time I've needed it was on a 32-bit 
CentOS Linux system, and then I just set CFLAGS myself.

-- 
Peter Karman  .  http://peknet.com/  .  peter@peknet.com

Re: [kinosearch-commits] r5736 - trunk/perl/buildlib/KinoSearch

[Peter Karman <pe...@peknet.com>]

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.
> 

amen.

> 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
> __LITTLE_ENDIAN__=1
> _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  .  http://peknet.com/  .  peter@peknet.com

Re: [KinoSearch] [Lucy] Re: [kinosearch-commits] r5736 - trunk/perl/buildlib/KinoSearch

[Marvin Humphrey <ma...@rectangular.com>]

On Sat, Jan 23, 2010 at 08:58:07PM -0600, Peter Karman wrote:
> yes, leaving the flag off is fine. 

OK, good.

I broke PowerPC builds by adding -march=i486, though.  Natch.

So we're not done yet.

> The only time I've needed it was on a 32-bit CentOS Linux system, and then I
> just set CFLAGS myself.

Same here.  A quick test on a Debian Etch system seems to indicate that it's
not necessary there.  However, when I was researching this, I saw on the gcc
list that the default target is i386, which many people think is whack.

I think we could solve this for any one machine by adding -march=native, but
that would mess up the packagers.

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."

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.

Marvin Humphrey


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