Perhaps I can redeem myself. The code contains such gems of clarity as:
if ((*this).nat_t::operator<(b))
{
r = znat_t(b.nat_t::operator-(*this));
r.sign = b.sign;
} else
Don't ya just gotta love C++.
Bill.
On 3 December 2012 21:03, Bill Hart <[email protected]> wrote:
> 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 <[email protected]> wrote:
>> Bill Hart wrote:
>>>
>>> On 3 December 2012 19:39, leif <[email protected]> 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 <[email protected]
>>>>> <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 [email protected].
>> To unsubscribe from this group, send email to
>> [email protected].
>> 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 [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/mpir-devel?hl=en.
