On Dec 29, 2006, at 8:32 AM, Thorkil Naur wrote:
On Friday 01 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
Hello,
Thanks a lot for your reply. Here are some comments to this. As is customary,
I must apologise for the late reply (the response time for this conversation
seems to increase exponentially with time) which also may very well make some
of the comments totally out-dated.
On Friday 01
Hello Thorkil,
I am very sorry for the late reply. I have been extremely busy and I
wanted to give you a coherent answer.
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
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
Florian Weimer wrote:
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
Simon PJ and Bulat,
[the] ForeignPtr
solution [has] gotten a lot cheaper in GHC 6.6 than it used to be, so
it's worth trying. A merit of the approach is that is avoids fiddling
with the bignum allocator at all.
I actually did not know that until today; I have tried to keep up
with the
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 these are
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
; Esa Ilari Vuokko; John Meacham
| Cc: glasgow-haskell-users@haskell.org
| Subject: Replacement for GMP: Update
|
| 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
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
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 in the OpenSSL
Einar,
*This product includes software developed by the OpenSSL Project
*for use in the OpenSSL Toolkit (http://www.openssl.org/).
All developers would have to do is include the acknowledgment stated
above.
I think this is not bad for specific applications, but forcing this
upon all
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 with the
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 for
Hi Bulat,
don't forget about speed/memory efficiency of any programs that use
Integer just for case but really most of their numbers fit in 32/64
bits. i have one particular program of this type - it builds list of
all files on disk and Integers are used to save filesizes. i will be
glad if,
Simon,
(1) We'd be delighted to use a BSD-licensed alternative to GMP in GHC.
It's been a long-standing issue, just never quite important enough to
get done. If either or both of you are willing to put in the legwork,
and emerge with an implementation that we understand and can maintain,
we'd
Hi Bulat,
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
On Wed, Aug 02, 2006 at 03:22:57PM -0400, Peter Tanski wrote:
I suppose that one alternative is to let the library use 'malloc', but
make a foreign-pointer proxy for every bignum, which calls 'free' when
the GHC garbage collector frees it. Not as efficient, though.
Esa and I had discussed
On 8/3/06, John Meacham [EMAIL PROTECTED] wrote:
On Wed, Aug 02, 2006 at 03:22:57PM -0400, Peter Tanski wrote:
Esa and I had discussed the possibility of copying the value returned
from the Bignum lib into the GHC system, which certainly would not be
very memory efficient, but might be
Esa,
In the July thread, (Repost) Replacement for GMP as Bignum: ARPREC?
Haskell?; OS X and OpenSSL, you wrote:
In past, I tried to get rid of GMP by replacing it with libtommath
http://math.libtomcrypt.com/
But I have given up for now - because of related and unrelated
problems.
Since
Duncan Coutts wrote:
On Sun, 2006-07-30 at 20:02 +0100, Brian Hulley wrote:
Suppose for a moment that GHC did dynamically link gmp.dll, or indeed
HSbase.dll. Where exactly would these files go?
I'd install them in the same directory as ghc.exe because this directory has
to be on the %PATH%
Hi Peter,
Peter Tanski wrote:
In the July thread, (Repost) Replacement for GMP as Bignum: ARPREC?
Haskell?; OS X and OpenSSL, you wrote:
In past, I tried to get rid of GMP by replacing it with libtommath
http://math.libtomcrypt.com/
But I have given up for now - because of related
On Tue, 2006-08-01 at 17:05 +0100, Simon Marlow wrote:
Duncan Coutts wrote:
So where do I put the Gtk+ .dlls? At the moment I seem to have no choice
but to put them on the %PATH%. And thus the breakage ensues. Old
versions of Gtk+ that people have on their systems can interfere. Lots
of
Esa,
What I have written here might not be the most useful guide to
start with, but maybe it is of help for other interested souls.
Many thanks for the notes; it would probably be better if more than
one programmer worked on it.
* The memory handling:
The idea on most bignum libs is
Hi Peter,
Peter Tanski wrote:
(This may sound naieve): the in { size, used, payload, sign } are all
parts of the info-table for the payload and the RTS re-initialises the
mathlib on each invocation, right?
I hope my answer helps, but if it gets you more confused,
maybe it's just because I'm
Hey Esa,
Another great instructive email! Thanks again! I will keep this
response short because I am sure you are busy and you have been more
than helpful so far. I also need to get back to working through the
code...
I hope my answer helps, but if it gets you more confused,
maybe
Hello p,
Sunday, July 30, 2006, 7:21:07 AM, you wrote:
Leroy and even MLton uses GMP. Robert Dockins wrote a type-based
library for arbitrary that can (slowly) handle big numbers (up to
10^15), see http://www.eecs.tufts.edu/~rdocki01/typenats.html I don't
this don't have anything common
Hi
On 7/30/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
(Sorry for the repost: I needed to correct a few typos--thanks
Seth--and clarify a few things.)
GHC Task Ticket # 601 suggests replacing GMP with OpenSSL's Bignum library, BN.
I have two questions concerning this:
(1) Why not use the
[EMAIL PROTECTED] wrote:
GHC Task Ticket # 601 suggests replacing GMP with OpenSSL's Bignum
library, BN. I have two questions concerning this:
From the ticket, this looks very scary:
but its LGPL license is problematic for users of GHC
(it prohibits static linking of
On 7/30/06, Brian Hulley [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
GHC Task Ticket # 601 suggests replacing GMP with OpenSSL's Bignum
library, BN. I have two questions concerning this:
From the ticket, this looks very scary:
but its LGPL license is problematic for users of
On Sun, 2006-07-30 at 11:53 +0100, Brian Hulley wrote:
[EMAIL PROTECTED] wrote:
GHC Task Ticket # 601 suggests replacing GMP with OpenSSL's Bignum
library, BN. I have two questions concerning this:
From the ticket, this looks very scary:
but its LGPL license is problematic for
Esa Ilari Vuokko wrote:
On 7/30/06, Brian Hulley [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
GHC Task Ticket # 601 suggests replacing GMP with OpenSSL's Bignum
library, BN. I have two questions concerning this:
From the ticket, this looks very scary:
but its LGPL license
Duncan Coutts wrote:
On Sun, 2006-07-30 at 11:53 +0100, Brian Hulley wrote:
[EMAIL PROTECTED] wrote:
GHC Task Ticket # 601 suggests replacing GMP with OpenSSL's Bignum
library, BN. I have two questions concerning this:
From the ticket, this looks very scary:
but its LGPL license
Hi Duncan,
On 7/30/06, Duncan Coutts [EMAIL PROTECTED] wrote:
GHC only statically links Haskell code. It dynamically links to GMP and
the system C library and other C libs.
In Windows (mingw) GMP is linked in statically (even this dll-stuff is
bitrotted).
So you're fine.
On unix you can
Hi Brian,
On 7/30/06, Brian Hulley [EMAIL PROTECTED] wrote:
Still, a slight problem is that since there is one object file per source
file, the names of the object files give quite a lot of information away
about the structure of the program especially when they are arranged in a
module
Esa Ilari Vuokko wrote:
Hi Brian,
On 7/30/06, Brian Hulley [EMAIL PROTECTED] wrote:
Still, a slight problem is that since there is one object file per
source file, the names of the object files give quite a lot of
information away about the structure of the program especially when
they are
[EMAIL PROTECTED] wrote:
Brian,
The standard method of skirting the LGPL restriction and saving your
source code is to link dynamically in a separate step and then
distribute your program along with the dynamically linked LGPL'd
library. Compile with ghc -c (or with ghc -c -odir 'separate
On Sun, 2006-07-30 at 17:33 +0100, Brian Hulley wrote:
I think the main problem here is that I'm using Windows, so there is no way
to dynamically link with the runtime libraries - the GHC implementations
available for Windows only produce statically linked executables.
Perhaps Windows
Duncan Coutts wrote:
On Sun, 2006-07-30 at 17:33 +0100, Brian Hulley wrote:
I think the main problem here is that I'm using Windows, so there is
no way to dynamically link with the runtime libraries - the GHC
implementations available for Windows only produce statically linked
executables.
On Sun, 2006-07-30 at 19:03 +0100, Duncan Coutts wrote:
On Sun, 2006-07-30 at 17:33 +0100, Brian Hulley wrote:
I think part of the issue is that static linking is very convenient and
dynamic linking in this case would lead to some tricky administrative
problems.
Suppose for a moment that
On Sun, 2006-07-30 at 20:02 +0100, Brian Hulley wrote:
Suppose for a moment that GHC did dynamically link gmp.dll, or indeed
HSbase.dll. Where exactly would these files go?
I'd install them in the same directory as ghc.exe because this directory has
to be on the %PATH% for the command
On Mon, 2006-07-31 at 05:00 +1000, skaller wrote:
On Sun, 2006-07-30 at 19:03 +0100, Duncan Coutts wrote:
On Sun, 2006-07-30 at 17:33 +0100, Brian Hulley wrote:
I think part of the issue is that static linking is very convenient and
dynamic linking in this case would lead to some tricky
Duncan Coutts wrote:
On Sun, 2006-07-30 at 20:02 +0100, Brian Hulley wrote:
[snip]
app. When the app runs, Windows will first look in the app's
directory and therefore find the correct set of DLLs.
Yes, it's fine for distributing applications but not much good for
libraries.
Hi Duncan -
GHC Task Ticket # 601 suggests replacing GMP with OpenSSL's Bignum library, BN.
I have two questions concerning this:
(1) Why not use the ARbitrary PRECision Computation Package (ARPREC)
by David Bailey, Yozo Hida, Karthik Jeyabalan, Xiaoye Li and Brandon
Thompson? Here is a reference web page:
On Sat, 29 Jul 2006 21:45:21 -0400
[EMAIL PROTECTED] wrote:
GHC Task Ticket # 601 suggests replacing GMP with OpenSSL's Bignum library,
BN.
I have two questions concerning this:
(1) Why not use the ARbitrary PRECision Computation Package (ARPREC)
by David Bailey, Yozo Hida, Karthik
(Sorry for the repost: I needed to correct a few typos--thanks
Seth--and clarify a few things.)
GHC Task Ticket # 601 suggests replacing GMP with OpenSSL's Bignum library, BN.
I have two questions concerning this:
(1) Why not use the ARbitrary PRECision Computation Package (ARPREC)
by David
66 matches
Mail list logo
