Damn, I just did my first timing, and I have completely failed. Adding
100M integers together results in times just about identical with the
assembly optimised version of MPIR and significantly faster than the
generic C version.
I have failed woefully.
Bill.
On 3 December 2012 20:24, leif <not.rea...@online.de> wrote:
> 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.
>
--
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.
