On Jan 4, 8:21 pm, techtech wrote:
> On Jan 3, 1:55 pm, Cactus wrote:
>
> > But you could force a link by adding
> > /FORCE:multiple
> > Brian
>
> Useful trick, thanks. I also discovered how to use dumpbin to
> determine which MS runtime library was requested by a .lib or .dll.
> (See:http
On Jan 3, 1:55 pm, Cactus wrote:
> But you could force a link by adding
> /FORCE:multiple
> Brian
Useful trick, thanks. I also discovered how to use dumpbin to
determine which MS runtime library was requested by a .lib or .dll.
(See: http://www.davidlenihan.com/2008/01/choosing_the_correct_c
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
I've committed the changes to the code. The improvements are more
modest than I remember them being last night, but here are the new
timings as affected by the negacyclic convolution anyhow:
536608768/1: 8.4s / 9.9s (17.9%)
603684864/1: 10.3s / 10.5s
670760960/1: 11.3s / 12.6s (11.5%)
737837056/1:
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
21 matches
Mail list logo
