Hi everybody,
Does anybody know what this means and how to resolve it? I have updated
my hackage account and can upload via the web interface, just not via
cabal. cabal config file is new as well.
cabal upload -c dist/PrimitiveArray-0.5.2.0.tar.gz
Checking dist/PrimitiveArray-0.5.2.0.tar.gz...
Hi,
a bit late but here are my comments:
- my main (and in a way ``only'') concern is speed. At some point I'd
like my programs to consistently beat the pants off C ...
This won't happen soon, but when comparing to C it makes a difference
being able to say Haskell is x1.3 slower or x1.4
Awesome,
I have been playing with GHC 7.6.0 until today and been very happy. Btw.
isn't this the version that officially includes -fnew-codegen / HOOPL?
Because the new codegen is optimizing the my ADPfusion library nicely.
I lost 50% speed with new features, gained 100% with new codegen,
Hi,
well, rgbliste has type:
*Main :t rgbliste
rgbliste :: [(Integer, Integer, Integer)]
unless you have farbliste as well, in which case it is:
*Main :t rgbliste
rgbliste :: [(GHC.Word.Word16, GHC.Word.Word16, GHC.Word.Word16)]
Of course, with NoMonomorphismRestriction, the type becomes:
Hi,
Most, if not all could reasonably be implemented using type families --
though there is a potential O(n^2) instance problem. In KIS:PEY:2010,
there is an example for addition which you could look at.
That is, using the example
(1::Int) + (1::Double) would work out to (2::Double) instead of
Thanks,
that was a rather curious problem then. With more version annotations,
hackage compiled everything.
Thanks for for testing!
Gruss,
Christian
* Albert Y. C. Lai tre...@vex.net [31.03.2012 03:58]:
On 12-03-30 06:37 PM, Christian Höner zu Siederdissen wrote:
I fail to remember or
Hi,
could it be that the llvm version used for the hackage buildbot is too
old?
The newest version of my 'Biobase' library does not compile there:
http://hackage.haskell.org/packages/archive/Biobase/0.3.1.0/logs/failure/ghc-7.0
and this seems to be due to llvm being too old:
Hi,
if you know a student interested in applying her or his knowledge in
algorithms (especially graph optimization) please note her or him of
this opening or forward to interested parties.
PhD Position: Bioinformatics / Graph Optimization
We are looking for a Diploma / Masters student to join
Yes indeed, this is what some fusion code could look like. I deal with stuff
like this:
mk i j = enumFromN (i+1) (j-i-2) -- gen indices, sometimes index pairs
f i j k = T!(i,k) + T!(k+1,j) -- table lookup using some 2d tables
g i j k = fun i k + fun (k+1) j -- some funny calculation
z i j =
] On Behalf Of Roman Leshchinskiy
| Sent: 03 November 2010 10:55
| To: Christian Hoener zu Siederdissen
| Cc: glasgow-haskell-users@haskell.org
| Subject: Re: Loop optimisation with identical counters
|
| LLVM doesn't eliminate the counters. FWIW, fixing this would improve
performance
Thanks, I'll do some measurements on this with ghc7.
Gruss,
Christian
On 11/02/2010 01:23 PM, Simon Marlow wrote:
On 02/11/2010 08:17, Christian Höner zu Siederdissen wrote:
Hi,
is the following problem a job for ghc or the code generation backend
(llvm)?
We are given this program:
{-#
a bit. It's very easy to do in Core.
Roman
On 3 Nov 2010, at 10:45, Christian Hoener zu Siederdissen
choe...@tbi.univie.ac.at wrote:
Thanks, I'll do some measurements on this with ghc7.
Gruss,
Christian
On 11/02/2010 01:23 PM, Simon Marlow wrote:
On 02/11/2010 08:17, Christian Höner
Thanks that is *exactly* the problem I am having. The missing line breaks are
kind of weird.
I will try the newest head (which will mean getting about 20 libs to
compile...) and report back.
I left the core out intentionally because the vector library tends to produce
ugly core when it can
Thanks everybody for the answers.
Right now, it looks like this:
the indextype is abstracted out and I plan for Data.Ix and my own Data.FastIx
(or however to call it).
As I don't plan on creating all instances myself, Neils derive package looks
good -- once I
understand it completely; which I
) will be started.
Would there be hope that compiling the latest head instead of 2009/03/14 (rc1)
gives better results?
Note that each x_(k+1) is computationally more demanding than x_k.
Gruss,
Christian
Simon Marlow wrote:
Christian Hoener zu Siederdissen wrote:
when using parMap (or parList
Greetings,
when using parMap (or parList and demanding) I see a curious pattern in CPU
usage.
Running parMap rnf fib [1..100] gives the following pattern of used CPUs:
4,3,2,1,4,3,2,1,...
The fib function requires roughly two times the time if we go from fib(n) to fib(n+1), meaning that
Simon Marlow wrote:
Christian Hoener zu Siederdissen wrote:
when using parMap (or parList and demanding) I see a curious pattern
in CPU usage.
Running parMap rnf fib [1..100] gives the following pattern of used
CPUs:
4,3,2,1,4,3,2,1,...
How did you find out which CPU is being used?
Sorry
17 matches
Mail list logo
