On Aug 28, 8:04 pm, rjf wrote:
> On Aug 27, 5:16 pm, Juanjo
> wrote:
>
> > On Aug 27, 11:24 pm, rjf wrote:
>
> > > perhaps ECL does not have something like schedule-finalization. I
> > > think this is present in CMUCL, SBCL, Lispworks, and AllegroCL, at least.
>
> > ECL does have finalization
On Aug 27, 5:16 pm, Juanjo
wrote:
> On Aug 27, 11:24 pm, rjf wrote:
>
> > perhaps ECL does not have something like schedule-finalization. I
> > think this is present in CMUCL, SBCL, Lispworks, and AllegroCL, at least.
>
> ECL does have finalization but this is an overkill for the problem in
>
On Aug 28, 3:41 am, Nils Bruin wrote:
> On Aug 27, 5:16 pm, Juanjo
> wrote:
>
> > I have just uploaded some patches to our source repositories that
> > allow ECL coexist with a GMP library which uses other memory
> > allocation functions. The changes are available in the CVS and git
> > reposi
On Aug 27, 11:24 pm, rjf wrote:
> perhaps ECL does not have something like schedule-finalization. I
> think this is present in CMUCL, SBCL, Lispworks, and AllegroCL, at least.
ECL does have finalization but this is an overkill for the problem in
question -- it would slow down all bignum arithme
On Aug 27, 5:16 pm, Juanjo
wrote:
> I have just uploaded some patches to our source repositories that
> allow ECL coexist with a GMP library which uses other memory
> allocation functions. The changes are available in the CVS and git
> repositorieshttp://ecls.sf.net/download.html
> and will under
If you type 1+1 into maxima again and again, you will see
(%i1) 1+1
(%o1) 2
(%i2 1+1
(%o2) 2
...
(%i32000) 1+1
(%o32000) 2
At some point in the interaction consisting of about 80 pages,
it might occur to you that some of those answers were taking up
memory :)
as for searching in that
On Thu, Aug 27, 2009 at 9:28 AM, rjf wrote:
>
> It's nice that the "labels" issue has been resolved. It is fairly
> implausible that a user would
> type in 32,000 individual commands, so optimizing a search was an
> obvious issue.
> Of course lisp has hash tables. Also arrays.
> The idea that you
On Aug 27, 11:59 am, Nils Bruin wrote:
> On Aug 27, 9:07 am, rjf wrote:
>
> > Let GMP do its own memory allocation. After Lisp has itself allocated
> > a structure S with a pointer to a GMP-allocated object, it knows what
> > to do: either S is
> > used or not, determined by a garbage collect
- Original Message -
From: "Nils Bruin"
To: "sage-devel"
Sent: Thursday, August 27, 2009 5:07 PM
Subject: [sage-devel] Re: Using MPIR or GMP with multiple memory managers
On Aug 27, 3:46 am, Jason Moxham wrote:
> the source arguments to the mpz_* function
On Thu, 27 Aug 2009, rjf wrote:
> It seems that your basic problem is that you have a terrible interface
> to Maxima, even if this problem were fixed.
> A proper interface would not require Maxima to parse a character
> string for each command. There are
> many possible ways to do this, but poss
It's nice that the "labels" issue has been resolved. It is fairly
implausible that a user would
type in 32,000 individual commands, so optimizing a search was an
obvious issue.
Of course lisp has hash tables. Also arrays.
The idea that you were generating tens of thousands of symbols -- in
additi
On Aug 27, 9:07 am, rjf wrote:
> Let GMP do its own memory allocation. After Lisp has itself allocated
> a structure S with a pointer to a GMP-allocated object, it knows what
> to do: either S is
> used or not, determined by a garbage collection. When S is
> determined to be not used, mpz_clea
This thread is too long already, but I think it may not be dedundant
to point how how I wrote a linkage between Allegro Common Lisp and
GMP, and how (I suspect) most mature Lisp systems with a deterministic
garbage collector would do it.
Let GMP do its own memory allocation. After Lisp has itsel
On Thu, 27 Aug 2009, Nils Bruin wrote:
>
> On Aug 27, 3:46 am, Jason Moxham wrote:
>
>> the source arguments to the mpz_* functions are const pointers so the memory
>> they point to will not change (thru that pointer) , ie as long as c does not
>> alias a or b then GMP will not change a or b . Th
On Aug 27, 3:46 am, Jason Moxham wrote:
> the source arguments to the mpz_* functions are const pointers so the memory
> they point to will not change (thru that pointer) , ie as long as c does not
> alias a or b then GMP will not change a or b . The above code will work.
Excellent. So that giv
On Thursday 27 August 2009 03:43:52 Nils Bruin wrote:
> On Aug 26, 7:06 pm, Nils Bruin wrote:
>
> OK, so r and d would probably get allocated using
>
> mpz_t *r
> mp_ptr d
> r = (mpz_t) ecl_alloc(sizeof(mpz_t)+(c->_mp_size )*sizeof(limb))
> d = (mp_ptr) (r+1)
> r->_mp_size = c->_mp_size
> r->_mp_
On Thursday 27 August 2009 09:18:04 Juanjo wrote:
> On Aug 27, 4:06 am, Nils Bruin wrote:
> > mpz_init(&c)
> > mpz_add(&c,&a,&b)
> > d=ecl_alloc( (c->_mp_size )*sizeof(limb))
> > memcpy(d,c->_mp_alloc,c->_mp_size * sizeof(limb))
> > r=ecl_alloc(sizeof(mpz_t))
> > r->_mp_size = c->_mp_size
> > r->
On Thursday 27 August 2009 03:06:13 Nils Bruin wrote:
> On Aug 26, 5:19 pm, Jason Moxham wrote:
> > I think you mean you allready know the size that is big enough to hold
> > the answer , which is not the same as what GMP needs to allocate to
> > calculate the answer. For example to multiply two
On Aug 27, 4:06 am, Nils Bruin wrote:
> mpz_init(&c)
> mpz_add(&c,&a,&b)
> d=ecl_alloc( (c->_mp_size )*sizeof(limb))
> memcpy(d,c->_mp_alloc,c->_mp_size * sizeof(limb))
> r=ecl_alloc(sizeof(mpz_t))
> r->_mp_size = c->_mp_size
> r->_mp_d = d
> r->_mp_alloc = c ->_mp_size
> mpz_clear(&c)
> now we h
On Aug 26, 7:06 pm, Nils Bruin wrote:
OK, so r and d would probably get allocated using
mpz_t *r
mp_ptr d
r = (mpz_t) ecl_alloc(sizeof(mpz_t)+(c->_mp_size )*sizeof(limb))
d = (mp_ptr) (r+1)
r->_mp_size = c->_mp_size
r->_mp_d = d
r->_mp_alloc = c ->_mp_size
Looking at the code of mpz_array_init
On Aug 26, 5:19 pm, Jason Moxham wrote:
> I think you mean you allready know the size that is big enough to hold the
> answer , which is not the same as what GMP needs to allocate to calculate the
> answer. For example to multiply two ints of 2000 limbs and 3000limbs , the
> result may fit in 499
On Tuesday 25 August 2009 22:07:26 Juanjo wrote:
> On Aug 25, 9:59 pm, Jason Moxham wrote:
> > On Tuesday 25 August 2009 20:35:48 Juanjo wrote:
> > > I think that the cheapest solution is the one you suggested: allocate
> > > the bignums manually and hope that GMP does not reallocate them. This
>
On Aug 25, 9:59 pm, Jason Moxham wrote:
> On Tuesday 25 August 2009 20:35:48 Juanjo wrote:
> > I think that the cheapest solution is the one you suggested: allocate
> > the bignums manually and hope that GMP does not reallocate them. This
> > can be easily done in ECL, because the actual bignum c
On Aug 25, 12:59 pm, Jason Moxham wrote:
> GMP will still need to allocate memory for internal needs using its
> allocator,
> but it is freed again . If the destination operand has enough memory for the
> largest possible output +1 then this should be enough , although I dont know
> if we can
On Tuesday 25 August 2009 20:35:48 Juanjo wrote:
> On Aug 25, 7:28 pm, Nils Bruin wrote:
> > 4) cl_boot() in libecl.so calls mp_set_memory_functions to set the
> > memory functions, presumably on the copy of libgmp.a that has been
> > included in the build of libecl.so (libecl.so is certainly not
On Aug 25, 7:28 pm, Nils Bruin wrote:
> 4) cl_boot() in libecl.so calls mp_set_memory_functions to set the
> memory functions, presumably on the copy of libgmp.a that has been
> included in the build of libecl.so (libecl.so is certainly not
> advertising any dependencies on libgmp.so when I call
On Aug 25, 10:33 am, Martin Albrecht
wrote:
> Excuse my ignorance, I am sure this was answered a long time ago but I can't
> find it right now: why don't you just steal the memory manager back from GMP,
> i.e. why does ECL require the GMP memory manager to use its garbage collected
> memory?
Yes
> 1) sage is using gmp.so and is linked to that before libecl.so is even
> introduced. Thus, presumably sage is fully bound to libecl.so
> 2) sage initializes some of its "gmp integer pool"
> 3) upon "from sage.libs.ecl import *" I think libecl.so is "dlopen"-ed
> by sage (or does that happen befo
On Aug 25, 8:15 am, Bill Hart wrote:
> I think by "this capability" I mean the capability GMP/MPIR has of
> allowing user code to supply a memory manager.
>
> I mean, if that is global, doesn't it imply that user code can spy on
> the memory of other user code, say when it comes up for realloc?
>
On Aug 25, 3:41 am, Jason Moxham wrote:
> can you post me a list , there may be also mpn_* mpf_* __gmp_* etc , I think
> we will have to find ALL of them .
The experiment I did indicates that the libecl.so I created did *not*
have the property that I wanted:
1) sage is using gmp.so and is lin
I think by "this capability" I mean the capability GMP/MPIR has of
allowing user code to supply a memory manager.
I mean, if that is global, doesn't it imply that user code can spy on
the memory of other user code, say when it comes up for realloc?
And it is also potentially possible for one pro
I mean not to put too fine a point on it but isn't GMP used for
authentication on a certain major linux desktop?
I presume those guys thought of this, and statically link, or that I
am just wrong.
Bill.
On 25 Aug, 16:15, Bill Hart wrote:
> I think by "this capability" I mean the capability GMP
On Tuesday 25 August 2009 09:29:34 Nils Bruin wrote:
> On Aug 25, 12:21 am, Nils Bruin wrote:
> > On Aug 24, 11:41 pm, Robert Bradshaw
> >
> > wrote:
> > > I think you can still get an -fPIC libgmp.a directly from the same .o
> > > files that the libgmp.so uses. Have you tried just adding that
On Aug 25, 12:21 am, Nils Bruin wrote:
> On Aug 24, 11:41 pm, Robert Bradshaw
> wrote:
>
> > I think you can still get an -fPIC libgmp.a directly from the same .o
> > files that the libgmp.so uses. Have you tried just adding that flag
> > to mpir's make file?
Scratch previous: "./configure"
On Aug 24, 11:41 pm, Robert Bradshaw
wrote:
> I think you can still get an -fPIC libgmp.a directly from the same .o
> files that the libgmp.so uses. Have you tried just adding that flag
> to mpir's make file?
yes. You should look at their makefile. The following commands get
executed when I
On Aug 24, 2009, at 11:31 PM, Nils Bruin wrote:
>
> On Aug 24, 9:02 pm, Robert Bradshaw
> wrote:
>
>> I think you can do
>>
>> -Wl,-Bstatic -lgmp
>>
>> at the end.
>
> Wonderful, yes that makes the linker look for libgmp.a rather than
> ligmp.so. However, the libgmp.a that mpir builds yields th
On Aug 24, 9:02 pm, Robert Bradshaw
wrote:
> I think you can do
>
> -Wl,-Bstatic -lgmp
>
> at the end.
Wonderful, yes that makes the linker look for libgmp.a rather than
ligmp.so. However, the libgmp.a that mpir builds yields the "recompile
with -fPIC" complaint in this situation. I guess for
On Aug 24, 2009, at 6:07 PM, Nils Bruin wrote:
>
> On Aug 24, 4:51 pm, Jason Moxham wrote:
>
>> To me 1) sounds like the best option, if ecl links with it own
>> static version
>> of gmp , then as long as we aren't leaking any symbols everything
>> should just
>> work . We are leaking some
On Aug 24, 5:02 pm, Jason Moxham wrote:
> nlimbs(a+b)<=max(nlimbs(a),nlimbs(b))+1
> nlimbs(a*b)<=nlimbs(a)+nlimbs(b)
>
> but this is for the answer only , it doesn't include any temp space needed to
> perform the calculation eg we multiply by FFT and need approx 6x the space
> above. The temp sp
On Aug 24, 4:51 pm, Jason Moxham wrote:
> To me 1) sounds like the best option, if ecl links with it own static version
> of gmp , then as long as we aren't leaking any symbols everything should just
> work . We are leaking some symbols though , some by accident , and some on
> purpose for testi
On Monday 24 August 2009 23:54:39 Nils Bruin wrote:
> On Aug 24, 2:44 pm, Bill Hart wrote:
> > void
> > mp_set_memory_functions (void *(*alloc_func) (size_t),
> > void *(*realloc_func) (void *, size_t, size_t),
> > void (*free_func) (void *, size_
On Monday 24 August 2009 22:44:59 Bill Hart wrote:
> On 23 Aug, 21:42, Nils Bruin wrote:
> > The following problem came up while trying to use ecl as a library
> > inside sage:
> >
> > Both sage and ecl use GMP for their multi-precision arithmetic, and
> > both call mp_set_memory_functions to reg
On Mon, 24 Aug 2009, Bill Hart wrote:
> On 23 Aug, 21:42, Nils Bruin wrote:
>> The following problem came up while trying to use ecl as a library
>> inside sage:
>>
>> Both sage and ecl use GMP for their multi-precision arithmetic, and
>> both call mp_set_memory_functions to register their memory
On Aug 24, 2:44 pm, Bill Hart wrote:
> void
> mp_set_memory_functions (void *(*alloc_func) (size_t),
> void *(*realloc_func) (void *, size_t, size_t),
> void (*free_func) (void *, size_t))
> {
> if (alloc_func == 0)
> alloc_func = __gmp_def
On 23 Aug, 21:42, Nils Bruin wrote:
> The following problem came up while trying to use ecl as a library
> inside sage:
>
> Both sage and ecl use GMP for their multi-precision arithmetic, and
> both call mp_set_memory_functions to register their memory managers.
> This obviously doesn't work, s
On Aug 24, 2:11 pm, Nils Bruin wrote:
> On Aug 24, 7:55 am, Robert Dodier wrote:
>
> > The #$ macro constructs a string input stream and eventually
> > calls ADD-LINEINFO so it suffers from the bug I mentioned in
> > a previous message.
>
> The $NOLABELS variable seems to live in local scope so
On Aug 24, 7:55 am, Robert Dodier wrote:
> The #$ macro constructs a string input stream and eventually
> calls ADD-LINEINFO so it suffers from the bug I mentioned in
> a previous message.
The $NOLABELS variable seems to live in local scope somewhere, and
hence setting it does not affect the det
On Mon, Aug 24, 2009 at 8:10 AM, Golam Mortuza Hossain
wrote:
>
> Hi,
>
> On Mon, Aug 24, 2009 at 11:57 AM, William Stein wrote:
> > Anyway, patch up at
> >
> > http://trac.sagemath.org/sage_trac/ticket/6818
>
>
> Once above is merged following (possibly duplicate) bug
> should be closed
>
> http:
On Aug 24, 4:57 pm, William Stein wrote:
> Here's the responsible lisp code by the way from suprv1.lisp:
>
> [eyecancer]
now i got it, lisp is the real python (snake)
> Does lisp have hash tables? :-)
http://cl-cookbook.sourceforge.net/hashes.html has commands that
aren't used there.
but you
Hi!
On Aug 24, 4:53 pm, William Stein wrote:
> Yep, you are right, as I just verified (and added links back and forth).
> Simon King might also be happy, since he reported this bug.
I am :-))
Thank you for fixing it!
Cheers,
Simon
--~--~-~--~~~---~--~~
To post
Hi,
On Mon, Aug 24, 2009 at 11:57 AM, William Stein wrote:
> Anyway, patch up at
>
> http://trac.sagemath.org/sage_trac/ticket/6818
Once above is merged following (possibly duplicate) bug
should be closed
http://trac.sagemath.org/sage_trac/ticket/4731
Cheers,
Golam
--~--~-~--~~
On 8/24/09, William Stein wrote:
> I wonder -- if Maxima's basic arithmetic -- e.g., simplifying 1+2 --
> is super slow for some abstract reason, I wonder if it is taking
> longer and longer to compute the next prompt number. That would be
> pretty funny. Is there any way to turn off the promp
>> I wonder -- if Maxima's basic arithmetic -- e.g., simplifying 1+2 --
>> is super slow for some abstract reason, I wonder if it is taking
>> longer and longer to compute the next prompt number. That would be
>> pretty funny. Is there any way to turn off the prompt numbers?
>>
>> Help! What is g
> On Sun, Aug 23, 2009 at 11:38 PM, Nils Bruin wrote:
>> The slowing down has nothing to do with the sage interface, but
>> probably with the macro #$...$
The #$ macro constructs a string input stream and eventually
calls ADD-LINEINFO so it suffers from the bug I mentioned in
a previous message.
On Aug 24, 12:29 pm, andrejv wrote:
> If this is true the slowdown should be decreased if you add
> nolabels:true; at the top of in.
Wow, thanks for the insight, this works!!!
sage: maxima.eval('nolabels:true;')
'true'
sage: %timeit maxima.eval('1+1')
100 loops, best of 3: 4 ms per loop
sage: %
On 24 avg., 08:52, William Stein wrote:
> OK, that is very valuable to know. It means that independent of
> Sage, just evaluating the same expression "1+2" in Maxima repeatedly
> quickly leads to dramatic slowdowns. This seems to me like an
> absolutely huge bug in Maxima.
>
> I did another te
On Aug 24, 8:52 am, William Stein wrote:
>
> Help! What is going on!?
Fun thread to read... That's a maxima bug for sure. Has anyone tried
older versions of maxima? If it was better years ago, I think of
bisection to track down the change it introduced this. Has someone
asked on the mailing list
On Sun, Aug 23, 2009 at 11:38 PM, Nils Bruin wrote:
>
> On Aug 23, 8:15 pm, William Stein wrote:
>
>> On sage.math (Linux) I get the same timing as you:
>
> That's good, because that's where I did it.
>
> A sage with the ecl library interface is available in "/scratch/nbruin/
> sage-4.1.1-ecl-x86
On Sun, Aug 23, 2009 at 10:38 PM, Robert Dodier wrote:
> On 8/23/09, William Stein wrote:
>
>> In fact, I am mildly surprised that the above two timings between ecl
>> and maxima are so different. I wonder why it is an order of magnitude
>> faster to compute "(+ 1 2)" than to compute "(MEVAL #
On Aug 23, 8:15 pm, William Stein wrote:
> On sage.math (Linux) I get the same timing as you:
That's good, because that's where I did it.
A sage with the ecl library interface is available in "/scratch/nbruin/
sage-4.1.1-ecl-x86_64-Linux" so if you want to do timings for
yourself, you can.
Th
On 8/23/09, William Stein wrote:
> In fact, I am mildly surprised that the above two timings between ecl
> and maxima are so different. I wonder why it is an order of magnitude
> faster to compute "(+ 1 2)" than to compute "(MEVAL #$ 1 + 2$)".
> Perhaps in the second case the Maxima parser ha
On Sun, Aug 23, 2009 at 6:37 PM, Nils Bruin wrote:
>
> On Aug 23, 1:58 pm, William Stein wrote:
>> To whet our appetite though, might you do some benchmarks that compare
>> the speed of adding 2+2 via the library and via pexpect?
>
> OK, here's a little experiment. I thought adding 2 and 2 would
On Aug 23, 1:58 pm, William Stein wrote:
> To whet our appetite though, might you do some benchmarks that compare
> the speed of adding 2+2 via the library and via pexpect?
OK, here's a little experiment. I thought adding 2 and 2 would be too
hard for now, so I stuck with 1+2. Good news is that
Nils Bruin wrote:
> 7. The main drive for using ecl-as-a-library in sage is to get a
> faster interface with Maxima. If all options above turn out to involve
> a lot of work or are expensive to maintain, perhaps we need to find
> another way of speeding up the interface. As a side effect, we alr
On Aug 23, 4:08 pm, Martin Albrecht
wrote:
> > > Both sage and ecl use GMP for their multi-precision arithmetic, and
> > > both call mp_set_memory_functions to register their memory managers.
> > > This obviously doesn't work, since GMP only keeps track of one set of
> > > memory management routi
> > Both sage and ecl use GMP for their multi-precision arithmetic, and
> > both call mp_set_memory_functions to register their memory managers.
> > This obviously doesn't work, since GMP only keeps track of one set of
> > memory management routines. Ecl needs to use its memory manager, since
> >
On Sun, Aug 23, 2009 at 1:42 PM, Nils Bruin wrote:
>
> The following problem came up while trying to use ecl as a library
> inside sage:
>
> Both sage and ecl use GMP for their multi-precision arithmetic, and
> both call mp_set_memory_functions to register their memory managers.
> This obviously d
67 matches
Mail list logo
