Hi,
in Debian, we have the (well-known) problem of linking against libraries
using libgmp, in this case haskell-curl, which links against libcurl,
which links against gnutls, which uses libgmp since the latest release:
https://lists.debian.org/debian-haskell/2014/07/msg0.html
Are there any
problem, I have been
working with Dan Peebles on a nice set of MPFR bindings for my own purposes
using custom foreign prims.
I unpacked the main MPFR structures and let the ghc garbage collector move
everything around, like it does with GMP itself.
We've been able to get a version that ALMOST works
as PIC
(random name dropping here)? That would seem to be an elegant solution,
as it makes the distro packers happy and you would not have to maintain
a code copy.
In the past, I've linked a C++ library that used gmpxx against a
Haskell program by renaming all symbols starting with gmp to mygmp
using
On Thu, Jan 5, 2012 at 09:37, Simon Marlow marlo...@gmail.com wrote:
On 04/01/2012 21:00, Joachim Breitner wrote:
And would dlopen make a difference? RTLD_LOCAL sounds interesting...
Maybe, I haven't looked into that.
Beware of platform issues; IIRC RTLD_LOCAL doesn't do what one expects
On 04/01/2012 21:00, Joachim Breitner wrote:
Would linking gmp statically help? E.g. is there a way to link libgmp
into the RTS that the symbols are not visible to the linker any more?
It has slightly more licensing complications - GMP is LGPL, which
requires that the user of a program
seem to be an elegant solution,
as it makes the distro packers happy and you would not have to maintain
a code copy.
In the past, I've linked a C++ library that used gmpxx against a
Haskell program by renaming all symbols starting with gmp to mygmp
using objcopy. Unfortunately
Hi,
Am Mittwoch, den 04.01.2012, 22:00 +0100 schrieb Joachim Breitner:
And would dlopen make a difference? RTLD_LOCAL sounds interesting...
it seems that some OSs provide a RTLD_PRIVATE which does exactly what we
need: http://uw714doc.sco.com/en/man/html.3C/dlopen.3C.html
But unfortunately,
On Thu, Jan 5, 2012 at 13:53, Joachim Breitner nome...@debian.org wrote:
(But I am really wondering why the linker cannot do something that has
the same effect as objcopy --prefix-symbols, but on the fly.)
Some of them can; notably the binutils ld, which comes from the same source
as and uses
). Unfortunately, using dlopen does
not not help if some other shared library loads gmp regularly; there is
still only one global state. And statically linking gmp into the share
object does not work, as Simon predicted, because the static gmp library
is not compiled with PIC. The promising ld option -Bgroup does
On Thu, Jan 5, 2012 at 16:15, Joachim Breitner nome...@debian.org wrote:
Am Donnerstag, den 05.01.2012, 14:14 -0500 schrieb Brandon Allbery:
On Thu, Jan 5, 2012 at 13:53, Joachim Breitner nome...@debian.org
wrote:
(But I am really wondering why the linker cannot do something
* Simon Marlow:
One potential problem is that some Linux distributions really don't
like it if you bundle modified versions of external libraries.
However, I just don't see a way around this: GMP is inherently broken
because it has global state, so if you want two use it from two
clients
Hi,
Am Donnerstag, den 05.01.2012, 16:21 -0500 schrieb Brandon Allbery:
In any case, I am starting to approach the point of so will Debian
allow ghc to remain compatible with non-Linux?, since so far I'm
getting the distinct impression that solutions that work on Linux are
all that matter.
On 22/12/2011 22:58, Michal Konečný wrote:
Several issues related to the way GMP is included in GHC were publicly
discussed in the past with the goal of replacing GMP. As summarised in
this wiki by Peter Tanski
http://hackage.haskell.org/trac/ghc/wiki/ReplacingGMPNotes, the main
issues were
to use the system-provided libffi.
I am curious about the precise definition of bundled libraries. It
can be arranged that the GMP source is modified at GHC build time, so
the _source_ package contains the original unmodified tar of GMP
(except without documentation). Nevertheless
On Wed, Jan 4, 2012 at 11:50, Joachim Breitner nome...@debian.org wrote:
Now you might argue that gmp will never be the source of security
problems (although I woudn’t be too convinced about that). But even then
There's actually a patch for a (claimed to be minor potential) security
issue
packers happy and you would not have to maintain
a code copy.
In the past, I've linked a C++ library that used gmpxx against a Haskell
program by renaming all symbols starting with gmp to mygmp using objcopy.
Unfortunately, this is not portable and completely broke down on Mac OS when
Apple moved
, but for openbsd (where i'm doing a lot of haskell stuff),
it would be enough if the ghc sources would include not only a
(patched or unpatched) gmp source tree but also the ghc-specific
patches to gmp.
The rationale behind this polcicy (for openbsd, i can't speak for
debian): if there are 42 packages where
Dear all,
Several issues related to the way GMP is included in GHC were publicly
discussed in the past with the goal of replacing GMP. As summarised in this
wiki by Peter Tanski, the main issues were:
(1) Licensing
(2) Memory Structure; Simultaneous Access to GMP by Foreign (C) code
I assume you mean
http://hackage.haskell.org/trac/ghc/wiki/ReplacingGMPNotes#CurrentStatus
in which case, yes.
I assume that INTEGER_LIBRARY=integer-foo is an option when
compiling GHC itself and not when using GHC, correct?
Yes.
Great, thanks for your help Ian. Building GHC with
On Fri, Feb 12, 2010 at 01:17:13PM -0800, Greg Fitzgerald wrote:
I wonder if someone might be able to clear a few things up for me
about implementing Integer with GMP. First, is the link below the
most up-to-date information regarding GHC's situation?
http://hackage.haskell.org/trac/ghc
I wonder if someone might be able to clear a few things up for me
about implementing Integer with GMP. First, is the link below the
most up-to-date information regarding GHC's situation?
http://hackage.haskell.org/trac/ghc/wiki/ReplacingGMPNotes#BinaryDropinReplacementforGMP
I assume
On 25/11/2009 21:20, Bryan O'Sullivan wrote:
I get this error message, which suggests that the gmp-wrappers file
should be compiled with -fPIC but isn't being:
/usr/bin/ld:
libraries/integer-gmp/dist-install/build/cbits/gmp-wrappers.dyn_o:
relocation R_X86_64_PC32 against undefined symbol
I get this error message, which suggests that the gmp-wrappers file should
be compiled with -fPIC but isn't being:
/usr/bin/ld:
libraries/integer-gmp/dist-install/build/cbits/gmp-wrappers.dyn_o:
relocation R_X86_64_PC32 against undefined symbol `__gmpz_init' can not be
used when making a shared
chak:
Yitzchak Gale:
OK for the time
being, but it would be really, really good to be able to compile
ghc without gmp.
Well, just go ahead and write an alternative portable high-
performance implementation of Integer.
This idea of a Mac OS X binary with statically-linked
gmp is nice
Ian Lynagh [EMAIL PROTECTED] wrote:
the alternative would be to put the whole of $LDFLAGS into the Cabal
buildinfo, but that feels wrong to me.
Why so? By setting LDFLAGS, isn't the user asking for exactly that -
that those flags be used when linking?
paul
On Sun, Mar 30, 2008 at 03:37:35PM -0400, Paul Jarc wrote:
Ian Lynagh [EMAIL PROTECTED] wrote:
the alternative would be to put the whole of $LDFLAGS into the Cabal
buildinfo, but that feels wrong to me.
Why so? By setting LDFLAGS, isn't the user asking for exactly that -
that those flags
On Fri, Mar 21, 2008 at 01:44:37AM -0400, Paul Jarc wrote:
There are no --with-* flags for ncurses, so the only ways I can see to
say where ncurses is are the ones I'm already using, and which are
apparently insufficient - $CPPFLAGS/$LDFLAGS in the environment, and
Hi Paul,
On Sun, Mar 16, 2008 at 12:05:03AM -0400, Paul Jarc wrote:
make[1]: *** No rule to make target
`stage1//package/host/code.dogmap.org/foreign/ghc-6.8.2+spf+0/conf/gmp/include/gmp.h',
needed by `stage1/parser/cutils.o'. Stop.
Where is gmp.h actually installed?
Do you know where
Ian Lynagh [EMAIL PROTECTED] wrote:
On Sun, Mar 16, 2008 at 12:05:03AM -0400, Paul Jarc wrote:
make[1]: *** No rule to make target
`stage1//package/host/code.dogmap.org/foreign/ghc-6.8.2+spf+0/conf/gmp/include/gmp.h',
needed by `stage1/parser/cutils.o'. Stop.
Where is gmp.h actually
On Thu, Mar 20, 2008 at 01:29:26PM -0400, Paul Jarc wrote:
Ian Lynagh [EMAIL PROTECTED] wrote:
On Sun, Mar 16, 2008 at 12:05:03AM -0400, Paul Jarc wrote:
Second attempt: CPPFLAGS, LDFLAGS and mk/build.mk as above, and I also
gave --with-gmp-{includes,libraries} to ./configure. This ends
Ian Lynagh [EMAIL PROTECTED] wrote:
Sorry, I meant --with-gmp-{includes,libraries}.
Ah, ok. --with-gmp-* alone, without setting environment variables,
creating mk/build.mk, or anything else, gives the same error as
--with-gmp-* plus environment variables (No rule to make target
`stage1
I'm having some trouble building ghc against gmp installed in an
unusual place. (Actually, I install every package in its own
directory, but gmp seems to be the one causing trouble here.) First
attempt: adding the necessary -I, -L, and -Xlinker -R options to
CPPFLAGS/LDFLAGS when invoking
I understand that gmp is needed for the certain libraries like the
Prelude with Double and Integer.
But I do not understand why gmp is so deeply buried in the rts.
Are the basic types Int and Pointer not enough to write a compiler like ghc?
Cheers Christian
Don Stewart wrote:
However, its buried in the rts/distributed with the runtime, so that
users may optionally use that version, rather than finding and
installing their own external gmp package. On almost all platforms
though, the distributed-with-ghc gmp is unused.
But doesn't that mean
Christian.Maeder:
I understand that gmp is needed for the certain libraries like the
Prelude with Double and Integer.
But I do not understand why gmp is so deeply buried in the rts.
Are the basic types Int and Pointer not enough to write a compiler like ghc?
Integer is a good type
phercek:
Christian Maeder wrote:
I understand that gmp is needed for the certain libraries like the
Prelude with Double and Integer.
Why is GMP needed for Double? Based on the online report Double is
double precision floating; it does not need to represent arbitrary
big numbers.
I
gale:
Don Stewart wrote:
However, its buried in the rts/distributed with the runtime, so that
users may optionally use that version, rather than finding and
installing their own external gmp package. On almost all platforms
though, the distributed-with-ghc gmp is unused.
But doesn't
Don Stewart wrote:
on any system where an external libgmp is available, it will
be dynamically linked into the generated haskell programs,
and in-tree gmp isn't used at all (or compiled, or installed)
So on linux and *bsd, that should be fine.
On Mac OS X (as a special case of *bsd), we have
Christian Maeder wrote:
I understand that gmp is needed for the certain libraries like the
Prelude with Double and Integer.
Why is GMP needed for Double? Based on the online report Double is
double precision floating; it does not need to represent arbitrary
big numbers.
I thought
Hi
What is the situation on Windows? Does the standard
GHC binary on Windows have dynamically linked gmp
for binaries produced by ghc?
No, they are statically linked. (Please, can no one start discussing
licensing, people already know there are issues with it, and I get
plenty of traffic
Hello,
On Thursday 17 January 2008 17:57, Christian Maeder wrote:
I understand that gmp is needed for the certain libraries like the
Prelude with Double and Integer.
But I do not understand why gmp is so deeply buried in the rts.
Are the basic types Int and Pointer not enough to write
Yitzchak Gale:
OK for the time
being, but it would be really, really good to be able to compile
ghc without gmp.
Well, just go ahead and write an alternative portable high-
performance implementation of Integer.
This idea of a Mac OS X binary with statically-linked
gmp is nice
/ReplacingGMPNotes/
PerformanceMeasurements.
The statistics suggest that the OpenSSL BN has comparable
performance to the GMP, especially for smaller numbers.
Some note about the (very confusing) licensing issues regarding
OpenSSL would also be nice.
I will add this to the wiki. In short
On Sep 14, 2007, at 9:14 AM, Benedikt Huber wrote:
| I've been struggling using FFI bindings to libraries which rely
on the
| GNU Mp Bignum library (gmp).
It's an issue that bites very few users, but it bites them hard.
It's also tricky, but not impossible, to fix. The combination
Peter Tanski wrote:
The one problem you will find with _all_ potential
replacement libraries is incompatible behaviour for bitwise functions:
they are implemented arithmetically in GMP but logically elsewhere (when
they are implemented at all).
I don't fully understand this... I made sure
I won't be at the hackathon I fear (and neither will Simon M) but I jotted down
some notes about how to replace GMP with a Haskell library
http://hackage.haskell.org/trac/ghc/wiki/ReplacingGMPNotes/HaskellLibrary
Simon
| -Original Message-
| From: [EMAIL PROTECTED] [mailto
| I've been struggling using FFI bindings to libraries which rely on the
| GNU Mp Bignum library (gmp) - this is apparently a well known problem
| (http://hackage.haskell.org/trac/ghc/ticket/311,
| http://hackage.haskell.org/trac/ghc/wiki/ReplacingGMPNotes).
| I do rely on using such libraries
Simon Peyton-Jones [EMAIL PROTECTED] writes:
Peter Tanski did exactly that (he's the author of the
ReplacingGMPNotes above), but he's been very quiet recently. I
don't know where he is up to. Perhaps someone else would like to
join in?
Since I live only five minutes away from this year's
neubauer:
Simon Peyton-Jones [EMAIL PROTECTED] writes:
Peter Tanski did exactly that (he's the author of the
ReplacingGMPNotes above), but he's been very quiet recently. I
don't know where he is up to. Perhaps someone else would like to
join in?
Since I live only five minutes away
Hello,
I've been struggling using FFI bindings to libraries which rely on
the GNU Mp Bignum library (gmp) - this is apparently a well known
problem (http://hackage.haskell.org/trac/ghc/ticket/311).
I do want to use some of those libraries however and so I started to
get them work on ghc
Hello,
I've been struggling using FFI bindings to libraries which rely on the
GNU Mp Bignum library (gmp) - this is apparently a well known problem
(http://hackage.haskell.org/trac/ghc/ticket/311,
http://hackage.haskell.org/trac/ghc/wiki/ReplacingGMPNotes).
I do rely on using such libraries
Hello Thorkil,
I updated the wiki Replacing GMP/The Current GMP Implementation page
with some introductory notes. I hope the pretty graphic cuts down on
a lot of wording necessary. There is no discussion of the Cmm
implementation as that is contained in Esa's posts to the GHC users
of
ARPREC, OpenSSL's BN, GMP and LibTomMath. ) I tested GMP and
OpenSSL's BN for reference.
I must confess that it took me a while to understand what you were
doing here
and I am still uncertain: For example, how many multiplications
were actually
performed for bit size 4096?
4096
September 2006 06:43, Peter Tanski wrote:
...
For a brief overview of the speed of the libraries I looked at
carefully, see
http://hackage.haskell.org/trac/ghc/wiki/ReplacingGMPNotes
(I added a few charts to show the speed of ARPREC, OpenSSL's BN, GMP
and LibTomMath. ) I tested GMP
Hello John,
Tuesday, November 28, 2006, 4:52:09 AM, you wrote:
The simple problem with Haskell and Integer is that, according to the
Standard, Integer is a primitive: it is consequently implemented as
part of the runtime system (RTS),
there is no requirement that Integer be a primitive. a
On Sat, Nov 18, 2006 at 04:46:24PM -0500, Peter Tanski wrote:
The simple problem with Haskell and Integer is that, according to the
Standard, Integer is a primitive: it is consequently implemented as
part of the runtime system (RTS), not the Prelude or any library
(though the interface
.
Donald,
Thanks for tip! Have you seen any of this code yourself?
Jeremy,
Dr. Sloane would be a good person to contact. For reference, the
last work on this seems to have been done in 2005. Tony Sloane
(asloane -at- ics dot mq dot edu dot au).
Patroklos Argyroundis did a port of GMP version
On Nov 19, 2006, at 3:20 PM, Jeremy Shaw wrote:
At Sun, 19 Nov 2006 13:46:10 -0500, Peter Tanski wrote:
What is the problem building GMP for PalmOS? According to the GMP
install documentation, it supports ARM and Motorola's m68k
processors, so you would not be using generic C code. You
p.tanski:
On Nov 19, 2006, at 3:20 PM, Jeremy Shaw wrote:
And, around this time, my interest in running yhi on PalmOS starts to
wane.
Awww... to my knowledge, that would be the first Haskell
implementation for PalmOS :) As I mentioned in a prior email, there
is a Haskell arbitrary
Hi Jeremy,
On Nov 17, 2006, at 10:34 PM, Jeremy Shaw wrote:
At Sat, 18 Nov 2006 00:44:32 +,
Neil Mitchell wrote
One advantage you probably haven't thought of is the size of the
binary. ...
On a related note -- dropping the gmp requirement would also make it
easier to port yhc to non
At Sun, 19 Nov 2006 13:46:10 -0500,
Peter Tanski wrote:
What is the problem building GMP for PalmOS? According to the GMP
install documentation, it supports ARM and Motorola's m68k
processors, so you would not be using generic C code. You are
probably also using PRC-Tools, correct
On Nov 17, 2006, at 7:24 PM, Claus Reinke wrote:
it seems that haskell versions of bignums is pretty much gone from
more recent discussions of gmp replacements. now, I assume that
there are lots of optimizations that keep gmp popular that one
wouldn't want to have to reproduce, so
it seems that haskell versions of bignums is pretty much gone from
more recent discussions of gmp replacements. now, I assume that
there are lots of optimizations that keep gmp popular that one wouldn't
want to have to reproduce, so that a haskell variant might not be
competitive even if one had
claus.reinke:
it seems that haskell versions of bignums is pretty much gone from
more recent discussions of gmp replacements. now, I assume that
there are lots of optimizations that keep gmp popular that one wouldn't
want to have to reproduce, so that a haskell variant might
for a substantial part of haskell uses?
One advantage you probably haven't thought of is the size of the
binary. Currently GMP adds about 50Kb on to the Yhc runtime, for what
in the most cases is probably an occasional addition. If the bytecode
for a bignum library was less than this then there could
At Sat, 18 Nov 2006 00:44:32 +,
Neil Mitchell wrote
One advantage you probably haven't thought of is the size of the
binary. Currently GMP adds about 50Kb on to the Yhc runtime, for what
in the most cases is probably an occasional addition. If the bytecode
for a bignum library was less
Hello all,
I made another update to the notes on Replacing GMP, at http://
hackage.haskell.org/trac/ghc/wiki/ReplacingGMPNotes . It's pretty
basic and you'd probably find it shabby, but comments, modifications
appreciated. I am still in the throes of trying to *portably* beat
GMP
the speed of ARPREC, OpenSSL's BN, GMP
and LibTomMath. I did not add speed tests for Crypto++ and Botan
because they don't measure up. The original timings I obtained for
them were based on their own benchmarks which are inadequate and (for
Crypto++) based on tuned assembly code only
Hello Peter,
Sorry for the late reply. From your latest communication which seems to be
Date: Sat, 12 Aug 2006 21:12:05 -0400
From: Peter Tanski [EMAIL PROTECTED]
Subject: Re: OpenSSL License (was Replacement for GMP: Update)
To: John Goerzen [EMAIL PROTECTED]
I am a bit uncertain where
On 21 August 2006 16:20, Bulat Ziganshin wrote:
Hello Simon,
Monday, August 21, 2006, 6:55:47 PM, you wrote:
Parallel major GC was worked on by Roshan James during his
internship here this summer, and we have some working code, but it
needs a lot more testing and tuning, and it may be
Bulat Ziganshin wrote:
Hello skaller,
Sunday, August 13, 2006, 4:34:14 AM, you wrote:
But the state of the art is then two stages behind the
requirement: Haskell still has to 'world stop' threads
to do a major collection.
is not exactly true. look at Non-stop Haskell
Hello Simon,
Monday, August 21, 2006, 6:55:47 PM, you wrote:
is not exactly true. look at Non-stop Haskell
Simply because it adds overhead (both in runtime and code complexity), and the
benefits are relatively modest.
i think that GC that don't stops the world is just a different
product.
Hello skaller,
Sunday, August 13, 2006, 4:34:14 AM, you wrote:
I know very little about Haskell, let alone GHC internals
me too. so it's better to wait for comments about your thoughts from
GHC team than from me. but at least i can said that
But the state of the art is then two stages behind
* Peter Tanski:
Quite right; my mistake: under the OpenSSL license a developer cannot
mention features of the software in advertising materials, so the
license grant of the GPL-OpenSSL program to the developer is void.
The reason I mentioned users only was that in the particular
problem we
Hello skaller,
Saturday, August 12, 2006, 7:06:15 AM, you wrote:
My point here is that actually this is a disastrous optimisation
in a multi-processing environment, because in general, the
assignment of a pointer means the store isn't write once.
:) all the variables rewritten is local to
On Sat, 2006-08-12 at 10:58 +0400, Bulat Ziganshin wrote:
Hello skaller,
Saturday, August 12, 2006, 7:06:15 AM, you wrote:
My point here is that actually this is a disastrous optimisation
in a multi-processing environment, because in general, the
assignment of a pointer means the
On 2006-08-10, Peter Tanski [EMAIL PROTECTED] wrote:
Summary: I finally settled on modifying OpenSSL, since that would be
the easiest to work with under GHC's hood (plain C code, not C++). I
have to:
Have you carefully investigated the OpenSSL license? We in Debian have
had repeated
Hello skaller,
Saturday, August 12, 2006, 12:34:54 PM, you wrote:
My point here is that actually this is a disastrous optimisation
in a multi-processing environment, because in general, the
assignment of a pointer means the store isn't write once.
:) all the variables rewritten is
John,
Have you carefully investigated the OpenSSL license? We in Debian
have
had repeated problems since the OpenSSL license is, as written,
incompatible with the GPL (even linking to OpenSSL is incompatible
with
the GPL). I would hate to have a situation where all GHC-compiled
programs
On Fri, 2006-08-11 at 09:34 +0400, Bulat Ziganshin wrote:
why you say that ForeignPtr is slow? afaik, malloc/free is slow, but
starting from ghc 6.6 speed of _using_ ForeignPtr is the same as for Ptr
Er, malloc/free is not slow .. its very fast. I implemented
an arena based allocator (one
| To: Bulat Ziganshin
| Cc: Peter Tanski; glasgow-haskell-users@haskell.org
| Subject: Re: Re[2]: Replacement for GMP: Update
|
| On Fri, 2006-08-11 at 09:34 +0400, Bulat Ziganshin wrote:
|
| why you say that ForeignPtr is slow? afaik, malloc/free is slow, but
| starting from ghc 6.6 speed
Einar Karttunen wrote:
On 10.08 11:16, Peter Tanski wrote:
Paragraph 6 of the OpenSSL (1998-2005) license states that:
* 6. Redistributions of any form whatsoever must retain the following
*acknowledgment:
*This product includes software developed by the OpenSSL Project
*for use
* Peter Tanski:
On the other hand, the OpenSSL FAQ at http://www.openssl.org/support/
faq.html#LEGAL2 mentions that some GPL programs do not allow
binary combination (static linking) or interoperation (dynamic
linking) with OpenSSL. Honestly I have not seen any GPL licenses
like this. The
Florian,
This is the offending part:
* 3. All advertising materials mentioning features or use of this
software
*must display the following acknowledgement:
*This product includes cryptographic software written by
* Eric Young ([EMAIL PROTECTED])
*The word
.
If the FFI was used for bignum then (talking about Windows OS for the
moment) the bignum implementation could just be supplied as a C DLL, perhaps
even several different C DLL's for people to choose which one they wanted to
distribute with their program based on speed vs licencing issues. Eg if GMP
with the rapid changes going on but until Simon Marlow posted the FFI
syntax patch on cvs-ghc-request I had not read into it that much. It
won't be too much trouble for me to do a bare FFI binding to GMP or
another library (people seem to be having problems with OpenSSL's
license) but what I have been
Brian,
Therefore I'd recommend that licenses for code used by GHC runtime
should be either BSD or public domain.
I agree. I was working on a rewrite of OpenSSL's BN from scratch--
maybe a rewrite of GMP would be better--but that is a huge
undertaking for no other reason than
John,
After all on the average call where an object of that
size is free already it is a single array lookup, we have:
(a) fetch pointer (one read)
(b) fetch next (one read)
(c) store next as current (one write)
This is true for memory access; it is not true for memory
allocation. I do
On Fri, 2006-08-11 at 18:56 -0400, Peter Tanski wrote:
John,
After all on the average call where an object of that
size is free already it is a single array lookup, we have:
(a) fetch pointer (one read)
(b) fetch next (one read)
(c) store next as current (one write)
This is true
projects together! Do the GMP thing
first, then investigate this later. We have quite a few bit-twidding
ideas that we have never followed up.
Simon
| -Original Message-
| From: Peter Tanski [mailto:[EMAIL PROTECTED]
| Sent: 10 August 2006 06:32
| To: Simon Peyton-Jones; Simon Marlow
On 10 August 2006 06:32, Peter Tanski wrote:
for the Makefile in ghc/rts, in lines 300-346,
GC_HC_OPTS += -optc-O3
--isn't this problematic? gcc, from -O2 on includes
-fgcse which
may *reduce* runtime performance in programs using
Einar,
In my previous email I wrote something potentially confusing (really
a typo):
For developers (commercial or open source), the OpenSSL license
only mentions redistribution of the OpenSSL code in binary form
(paragraph 2). In this context binary form means the complete
program
that force
license related things.
I think this is one reason GMP is being replaced.
ps. personally I don't think the advertising clause is bad, but
I think it is bad to force it on other users.
- Einar Karttunen
___
Glasgow-haskell-users mailing list
code compiled by GHC would be bad. I think the compiler
should not link applications by default to things that force
license related things.
I think this is one reason GMP is being replaced.
ps. personally I don't think the advertising clause is bad, but
I think it is bad to force it on other
There's one thing I don't entirely understand about the GMP problem. I understand that there are some limitations on GHC's ability to generate relocatable (and therefore dynamically linkable) code on x86 (a register allocation problem related to the mangler if I recall the comments in the code
Reilly Hayes on 2006-08-10 18:36:49 -0700:
There's one thing I don't entirely understand about the GMP problem.
I understand that there are some limitations on GHC's ability to
generate relocatable (and therefore dynamically linkable) code on x86
(a register allocation problem related
Reilly,
... this shouldn't prohibit linking
GMP in dynamically, should it? It's just a C library and GCC should
happily generate relocatable code. As a dynamically linked library,
there should be no tainting issues to worry about even if the
dynamically linked code is shipped
Simon PJ, Simon, Esa and John,
Here is an update on what I have been doing so far in making a grand
attempt to replace GMP.
(1) evaluate replacement libraries
LibTomMath:
Pros-
* has all the operators GMP offered
Cons
Hello Simon,
Wednesday, August 2, 2006, 4:05:51 PM, you wrote:
(2) We're concerned about performance. Replacing GMP, but losing
substantial performance on bignum-intensive programs would be
unattractive.
don't forget about speed/memory efficiency of any programs that use
Integer just
it accordingly.
the same binary that also wants to use GMP. (Of course, we could
*copy*
GMP, changing all the function names. That would eliminate the
problem!)
isn't it rather easy task for some automated tool? i think that even
existing tools may be found
I know copyrights are weak compared
1 - 100 of 158 matches
Mail list logo
