On Tue, Jan 5, 2010 at 12:49 PM, Bill Hart wrote:
> Certainly the code is available by svn.
>
> 2010/1/5 Case Vanhorsen :
>> On Tue, Jan 5, 2010 at 12:26 PM, Cactus wrote:
>>>
>>>
>>> On Jan 5, 8:03 pm, Bill Hart wrote:
Excellent work Brian!
>>>
>>> I hope Case will see whether these change
Certainly the code is available by svn.
2010/1/5 Case Vanhorsen :
> On Tue, Jan 5, 2010 at 12:26 PM, Cactus wrote:
>>
>>
>> On Jan 5, 8:03 pm, Bill Hart wrote:
>>> Excellent work Brian!
>>
>> I hope Case will see whether these changes have had any impact on his
>> memory allocation dicovery and
On Tue, Jan 5, 2010 at 12:26 PM, Cactus wrote:
>
>
> On Jan 5, 8:03 pm, Bill Hart wrote:
>> Excellent work Brian!
>
> I hope Case will see whether these changes have had any impact on his
> memory allocation dicovery and his bug.
>
> The change to alloca makes some things faster and others slower
On Jan 5, 8:03 pm, Bill Hart wrote:
> Excellent work Brian!
I hope Case will see whether these changes have had any impact on his
memory allocation dicovery and his bug.
The change to alloca makes some things faster and others slower :-(
Brian
--
You received this message because you are
Excellent work Brian!
Bill.
2010/1/5 Cactus :
>
>
> On Jan 5, 7:11 pm, Bill Hart wrote:
>> I doubt it. In the test code you have:
>>
>> ASSERT_ALWAYS (putc ((size >> (j*8)) & 0xFF, fp) != EOF);
>>
>> should that 0xFF be 0xFFLL or something like that on Windows?
>
> I found the bug - its in lines
On Jan 5, 7:11 pm, Bill Hart wrote:
> I doubt it. In the test code you have:
>
> ASSERT_ALWAYS (putc ((size >> (j*8)) & 0xFF, fp) != EOF);
>
> should that 0xFF be 0xFFLL or something like that on Windows?
I found the bug - its in lines 80-82 in inp_raw.c
if (sizeof (csize) > 4 && csize & 0x8
I doubt it. In the test code you have:
ASSERT_ALWAYS (putc ((size >> (j*8)) & 0xFF, fp) != EOF);
should that 0xFF be 0xFFLL or something like that on Windows?
Bill.
2010/1/5 Cactus :
>
>
> On Jan 5, 8:10 am, Cactus wrote:
>> On Jan 4, 8:02 pm, Cactus wrote:
>>
>> > On Jan 4, 6:56 pm, Bill Har
On Jan 5, 8:10 am, Cactus wrote:
> On Jan 4, 8:02 pm, Cactus wrote:
>
> > On Jan 4, 6:56 pm, Bill Hart wrote:
>
> > > It looks like we have the following in mpir.h:
>
> > > #if defined (_CRAY) && ! defined (_CRAYMPP)
> > > /* plain `int' is much faster (48 bits) */
> > > #define __GMP_MP_SIZE_
GPL and not LGPL? I suppose that is not a problem, so long as it is
not built as part of the library...
Bill.
2010/1/5 Cactus :
>
>
> On Jan 5, 8:10 am, Cactus wrote:
>> On Jan 4, 8:02 pm, Cactus wrote:
>>
>>
>>
>> > On Jan 4, 6:56 pm, Bill Hart wrote:
>>
>> > > It looks like we have the follo
On Jan 5, 8:10 am, Cactus wrote:
> On Jan 4, 8:02 pm, Cactus wrote:
>
>
>
> > On Jan 4, 6:56 pm, Bill Hart wrote:
>
> > > It looks like we have the following in mpir.h:
>
> > > #if defined (_CRAY) && ! defined (_CRAYMPP)
> > > /* plain `int' is much faster (48 bits) */
> > > #define __GMP_MP_S
On Jan 4, 8:02 pm, Cactus wrote:
> On Jan 4, 6:56 pm, Bill Hart wrote:
>
>
>
> > It looks like we have the following in mpir.h:
>
> > #if defined (_CRAY) && ! defined (_CRAYMPP)
> > /* plain `int' is much faster (48 bits) */
> > #define __GMP_MP_SIZE_T_INT 1
> > typedef int
On Jan 4, 6:56 pm, Bill Hart wrote:
> It looks like we have the following in mpir.h:
>
> #if defined (_CRAY) && ! defined (_CRAYMPP)
> /* plain `int' is much faster (48 bits) */
> #define __GMP_MP_SIZE_T_INT 1
> typedef int mp_size_t;
> typedef int mp_
On Mon, Jan 4, 2010 at 10:59 AM, Bill Hart wrote:
> Could you also place traces in memory.c in the default allocate and
> reallocate functions, and in tal-reent.c in the default allocate
> function to see where these allocations are actually being made. You
> might also stick a trace in mpz/mul.c
Could you also place traces in memory.c in the default allocate and
reallocate functions, and in tal-reent.c in the default allocate
function to see where these allocations are actually being made. You
might also stick a trace in mpz/mul.c to see what is being allocated
there.
I'd be interested in
It looks like we have the following in mpir.h:
#if defined (_CRAY) && ! defined (_CRAYMPP)
/* plain `int' is much faster (48 bits) */
#define __GMP_MP_SIZE_T_INT 1
typedef int mp_size_t;
typedef int mp_exp_t;
#else
#define __GMP_MP_SIZE_T_INT 0
typed
On Mon, Jan 4, 2010 at 10:52 AM, Cactus wrote:
>
>
> On Jan 4, 6:38 pm, Bill Hart wrote:
>> If it is the latter then here is the relevant code:
>>
>> wsize = usize + vsize;
>>
>> .
>>
>> if (wp == up || wp == vp)
>> {
>> free_me = wp;
>> free_me_size = w
On Mon, Jan 4, 2010 at 10:38 AM, Bill Hart wrote:
> If it is the latter then here is the relevant code:
>
> wsize = usize + vsize;
>
> .
>
> if (wp == up || wp == vp)
> {
> free_me = wp;
> free_me_size = w->_mp_alloc;
> }
> else
> (*__gmp_fr
In fact from
A = __GMP_ALLOCATE_FUNC_LIMBS (2 * K * (nprime + 1));
I surmise that for an FFT of length K with n' bits per coefficient, it
requires 2*K*(n'+1) *bits*. Now K*n' should be 2 times the input bit
size. So it is requesting 4 times the input bit size. It also
allocates some pointers and
On Jan 4, 6:38 pm, Bill Hart wrote:
> If it is the latter then here is the relevant code:
>
> wsize = usize + vsize;
>
> .
>
> if (wp == up || wp == vp)
> {
> free_me = wp;
> free_me_size = w->_mp_alloc;
> }
> else
> (*__gmp_free_f
If it is the latter then here is the relevant code:
wsize = usize + vsize;
.
if (wp == up || wp == vp)
{
free_me = wp;
free_me_size = w->_mp_alloc;
}
else
(*__gmp_free_func) (wp, w->_mp_alloc * BYTES_PER_MP_LIMB);
w->_mp_all
This would be using the FFT. And the FFT should in theory require 4
times the input bit size in order to do the squaring. So to multiply
integers of 2^31 bits, it will request 2^30 bytes of memory. This is
all assuming that the FFT is written to use memory fairly efficiently.
This is in addition to
On Jan 4, 2:43 pm, Bill Hart wrote:
> uintptr_t is a c99 feature. So it "exists" on linux, but formally only
> in c99 mode. I'm not keen to switch MPIR to c99. But we can define
> something in mpir.h which on Windows in uintptr_t and on linux is the
> same size as an mp_limb_t or whatever (I thi
uintptr_t is a c99 feature. So it "exists" on linux, but formally only
in c99 mode. I'm not keen to switch MPIR to c99. But we can define
something in mpir.h which on Windows in uintptr_t and on linux is the
same size as an mp_limb_t or whatever (I think it is the case that an
mp_limb_t should alwa
On Jan 4, 2:23 pm, Case Vanhorsen wrote:
> On Mon, Jan 4, 2010 at 1:07 AM, Cactus wrote:
>
> > On Jan 4, 8:35 am, Cactus wrote:
> >> On Jan 4, 3:26 am, Case Vanhorsen wrote:
>
> >> > On Sun, Jan 3, 2010 at 12:33 PM, Cactus wrote:
>
> >> > > On Jan 3, 8:15 pm, Case Vanhorsen wrote:
> >> > >>
On Jan 4, 2:07 pm, Case Vanhorsen wrote:
> On Mon, Jan 4, 2010 at 12:35 AM, Cactus wrote:
>
> > On Jan 4, 3:26 am, Case Vanhorsen wrote:
> >> On Sun, Jan 3, 2010 at 12:33 PM, Cactus wrote:
>
> >> > On Jan 3, 8:15 pm, Case Vanhorsen wrote:
> >> >> Hello,
>
> >> >> I discovered an interesting
On Mon, Jan 4, 2010 at 1:07 AM, Cactus wrote:
>
>
> On Jan 4, 8:35 am, Cactus wrote:
>> On Jan 4, 3:26 am, Case Vanhorsen wrote:
>>
>>
>>
>> > On Sun, Jan 3, 2010 at 12:33 PM, Cactus wrote:
>>
>> > > On Jan 3, 8:15 pm, Case Vanhorsen wrote:
>> > >> Hello,
>>
>> > >> I discovered an interesting
On Mon, Jan 4, 2010 at 12:35 AM, Cactus wrote:
>
>
> On Jan 4, 3:26 am, Case Vanhorsen wrote:
>> On Sun, Jan 3, 2010 at 12:33 PM, Cactus wrote:
>>
>> > On Jan 3, 8:15 pm, Case Vanhorsen wrote:
>> >> Hello,
>>
>> >> I discovered an interesting memory allocation behavior on Windows vs.
>> >> Linu
On Jan 4, 8:35 am, Cactus wrote:
> On Jan 4, 3:26 am, Case Vanhorsen wrote:
>
>
>
> > On Sun, Jan 3, 2010 at 12:33 PM, Cactus wrote:
>
> > > On Jan 3, 8:15 pm, Case Vanhorsen wrote:
> > >> Hello,
>
> > >> I discovered an interesting memory allocation behavior on Windows vs.
> > >> Linux. I wa
On Jan 4, 3:26 am, Case Vanhorsen wrote:
> On Sun, Jan 3, 2010 at 12:33 PM, Cactus wrote:
>
> > On Jan 3, 8:15 pm, Case Vanhorsen wrote:
> >> Hello,
>
> >> I discovered an interesting memory allocation behavior on Windows vs.
> >> Linux. I was testing GMPY on 64-bit Windows when I stumbled int
On Sun, Jan 3, 2010 at 12:33 PM, Cactus wrote:
>
>
> On Jan 3, 8:15 pm, Case Vanhorsen wrote:
>> Hello,
>>
>> I discovered an interesting memory allocation behavior on Windows vs.
>> Linux. I was testing GMPY on 64-bit Windows when I stumbled into this.
>> GMPY replaces the native MPIR memory all
I made both issues into trac tickets. See #269 and #270. One is a
blocker for MPIR 1.3 as it regards a serious bug by the looks of it.
Bill.
2010/1/3 Cactus :
>
>
> On Jan 3, 8:15 pm, Case Vanhorsen wrote:
>> Hello,
>>
>> I discovered an interesting memory allocation behavior on Windows vs.
>> L
On Jan 3, 8:15 pm, Case Vanhorsen wrote:
> Hello,
>
> I discovered an interesting memory allocation behavior on Windows vs.
> Linux. I was testing GMPY on 64-bit Windows when I stumbled into this.
> GMPY replaces the native MPIR memory allocation routines with Python's
> memory allocator. If I e
32 matches
Mail list logo
