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-
*
33 matches
Mail list logo
