Bill Hart wrote:
On 3 December 2012 19:39, leif <not.rea...@online.de> wrote:
Bill Hart wrote:
You can make that change if you want, but obviously it will slow things
down for the many 32 bit apple users out there.
I have no problem with that though, as they obviously don't care about
speed.
:-)
That's why I also suggested inverting the logic:
That won't be necessary as of later tonight (hopefully). I have been
writing a new "littlenum" library in C++ for people who require such
performance tradeoffs. It is guaranteed that this new library will be
sufficient for all 32 bit Apple user's needs. I'll put it up on my
github later tonight and announce it on mpir-devel, so stay tuned.
Probably best to use popen("bc ...") in the C functions (and parse its
output). Alternatively call Python instead of bc, which might perform
even "better". And/or implement the functions operating on single limbs
with shell scripts using 'expr'.
-leif
I think I will call the library SLOWMATH (Super Ludicrously Optimised
Werkzeug). I currently call it SIMPLE (stupidly implemented
mathematics platform light edition), but that just doesn't have the
right ring to it.
Anyway, I best get back to it. I still have more than 30 functions to
write before it is done! And I need some timing comparisons with MPIR
before I can be truly happy...
Bill.
# 32bit apple darwin doesn't like our PIC format asm code
case $host in
i[34567]86-apple-darwin*|
pentium*-apple-darwin*|
prescott-apple-darwin*|
core-apple-darwin*)
path="x86/applenopic" ;;
*-apple-darwin*) # assume Core2 or later
path="x86/applenopic/core2 x86/applenopic" ;;
*) ;;
esac
Not sure whether we also have to add some old AMDs as well. (Reading
config.guess would perhaps enlight me... Although AFAIK Apple only used
Opterons in some machines, which hopefullyTM run 64-bit MacOS only.)
-leif
Patching configure only in sage seems ok. I doubt the diff will be
large. Probably a handful of lines. It shouldn't change any other files
as far as I'm aware.
Bill.
On Monday, 3 December 2012, leif wrote:
Jean-Pierre Flori wrote:
On Monday, December 3, 2012 6:35:15 PM UTC+1, Bill Hart wrote:
Time to apply the crumb test to JP's beard with a
fine-toothed comb!
By the way, shouldn't Sage be a little faster on my Amstrad
PC1512?
Bill.
On 3 December 2012 17:29, leif <not.r...@online.de
<javascript:>>
wrote:
> Jean-Pierre Flori wrote:
>>
>>
>>
>> On Monday, December 3, 2012 6:13:57 PM UTC+1, leif wrote:
>>
>> Jean-Pierre Flori wrote:
>> > Further info:
>> > - the result of ./config.guess is
nehalem-apple-darwin9.8.0,
>> which is
>> > not one dealt with in MPIR configure.in
<http://configure.in>
<http://configure.in> <http://configure.in> for
>>
>> the "32 bit apple darwin
>> > doesn't like our PIC format asm code".
>> > - and so we get MPN_PATH=" x86/nehalem x86
generic"
>>
>> ... then the -march=core-i7 was pretty correct.
>>
>> Who t** f*** runs a 32-bit operating system on such a
machine? (Dual
>> quad-core Xeon even IIRC) ;-)
>>
>> I agree :)
>> And that's the reason nobody complained until we
explicitely pushed
>> people to do so :)
>
>
> Well, YOU asked for it, so it's definitely your fault...
;-)
>
>
>
> -leif
In fact I just wanted to get rid of the dirty piece of code in
sage spkg
install script and hoped that nobody would actually answer on
sage-devel
so that the removal gets undetected.
How about changing
# 32bit apple darwin doesn't like our PIC format asm code
case $host in
core2-apple-darwin* | penryn-apple-darwin*)
path="x86/applenopic/core2 x86/applenopic" ;;
prescott-apple-darwin* | pentium4-apple-darwin*)
path="x86/applenopic" ;;
pentium3-apple-darwin* | pentium2-apple-darwin*)
path="x86/applenopic" ;;
i686-apple-darwin* | pentiumpro-apple-darwin*)
path="x86/applenopic" ;;
core-apple-darwin*) path="x86/applenopic" ;;
*) ;;
esac
to just
# 32bit apple darwin doesn't like our PIC format asm code
case $host in
core2-apple-darwin* | penryn-apple-darwin*)
path="x86/applenopic/core2 x86/applenopic" ;;
*-apple-darwin*) path="x86/applenopic" ;;
*) ;;
esac
? (As far as I can see, the above snippet is in the x86/x86_64 (and
32-bit OS/ABI) branch, so we don't have to deal with other archs
than these there.)
Otherwise the build will (sooner or later) fail in exactly the same
way on newer CPUs on 32-bit Darwin.
Btw, it would probably be better to use the applenopic/core2 path on
any post-Core2 CPU as well. Then we'd have to invert the logic,
such that the x86/applenopic/core2 path is *not* chosen / added on
i[34567]86-|pentium*-|__prescott-|core- (all with 'apple-darwin*'
appended), but on everything else, hoping that the former list is
complete. (We won't have to add CPUs to that list as time goes by,
in contrast to the post-Core2 list.)
For the sake of Sage, it's probably better to patch MPIR 2.6.0's
'configure' (i.e., the *generated* file) rather than 'configure.in
<http://configure.in>' (autoreconfing afterwards, which usually
causes lots of file changes) until 2.6.1 (with such a fix) is out.
-leif
--
() The ASCII Ribbon Campaign
/\ Help Cure HTML E-Mail
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To post to this group, send email to mpir-devel@googlegroups.com.
To unsubscribe from this group, send email to
mpir-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/mpir-devel?hl=en.
