Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
Hello Haskellers out there!
I have the feeling that questions on performance arise more often and that the knowledge on which functions/algorithms/libraries are fast and stable is sparse.
There are of course libraries like Criterion which allow to make measurements on one's own, and there is the profiler which can be invoked by
> ghc -O2 --make program.hs -prof -auto-all
> ./program +RTS -s
as excellently explained by #DonStewart in Tools for analyzing performance of a Haskell program
I know that:
the use of read and show is usually a bottleneck (for the read-function in the case of numbers there is the Numeric package which brings a performance speedup
and there are the Sequence, Array, Vector and Map libraries, which are often better fit to solve a problem than to use lists or nested lists
Text and Bytestring are a better option than String
I recently saw that even the use of the standard number generator slows down a program significantly and that mwc-random is a lot faster.
Also the answers of Python faster than compiled Haskell? revealed that the standard sorting algorithm is definitely improvable
The usage of Int rather than Integer, BangPatterns and strict folds often yield an increase in performance
There are conduit and pipes to "stricten" IO, (which I have to admit I haven't used yet)
type signatures are general an improvement
What are other common pitfalls and bottlenecks one tends to use?
How to solve those?
The topics that come to my mind are:
functions
data structures
algorithms
LANGUAGE extensions (for GHC)?
compiler options?
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
How is distributed memory parallelism handled in Rust? By that, I mean language constructs, libraries, or other features to handle computing on something like a cluster akin to what MPI provides C, but not necessarily using the same primitives or methodology. In the Rustonomicon, I see a discussion of threads and concurrency, but I don't see any discussion on parallelizing across multiple computers.
To the best of my knowledge, there isn't really anything built into the language for distributed computing (which is understandable, since that's arguably not really the language's major focus, or at least wasn't back in the day). I don't believe there's any particularly popular crate or another for distributed computing either. Actix is probably the only actor crate that has achieved any traction, and it supports HTTP, but I don't think it is targeted at HPC/supercomputer setups. You also definitely would want to check out Tokio, which seems to be pretty much the library for asynchronous programming in Rust, and is specifically targeted towards network IO operations.
At the present point in time, if you're looking to replicate MPI, my guess would be that your best bet is to use FFI to a C-based MPI library. It appears that there's been a handful of attempts to create bindings to MPI for Rust, but I'm not sure that any of them are particularly complete.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 5 years ago.
Improve this question
I studied how to optimize algorithms for multiprocessor systems. Now I would understand in main lines how these algorithms can be transformed into code.
I know that exist some libraries MPI based that helps the developement of software portable to different type of systems, but is right the word "portable" that makes me confused: how the program can be authomatically adapted to an arbitrary number of processors at runtime, since this is an option of mpirun? How the software can decide the proper topology (mesh, hypercube, tree, ring, etc)? The programmer can specify the preferred topology through MPI?
you start the application with a fixed number of cores. Thus, you cannot automatically adapted to an arbitrary number of processors at runtime.
You can tune your software to the topology of your cluster. This is really advanced and for sure not portable. It only makes sense if you have a fixed cluster and are striving for the last bit of performance.
Best regards, Georg
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
As far as I know the main difference between declarative and imperative programming is the fact that in declarative programming you rather specify what the problem is, while in imperative programming you state exactly how to solve a problem.
However it is not entirely clear for me when to use one over another. Imagine you are imposed to solve a certain problem, according to which properties you decide to tackle this down declaratively (i.e using prolog) or imperatively (i.e using Java)? For what kind of problems would you prefer to use one over the other?
Imperative programming is closer to what the actual machine performs. This is a quite low level form of programming, and the more complex your application grows, the harder it will be for you to grasp all details at such a low level. On the plus side, being close to the machine, you can write quite performant code if you are good at that.
Declarative programming is more abstract and higher level: With comparatively little code, you can express quite sophisticated relationships in a way that can be more easily seen to be correct.
To see an important difference, compare for example pure Prolog with Java: Suppose I take away one of the rules in a Prolog program. I know a priori that this can make the program at most more specific: Some things that held previously may now no longer hold.
On the other hand, suppose I take away a statement in a Java program: Nothing much can be said about the effect in general. The program may even no longer compile.
So, changes in an imperative program can have very unforeseen effects, and are extremely hard to reason about, because there are few guarantees and invariants, and many things are implicit in some global state of the program. This makes imperative programming very error-prone.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I was reading about primecoin when it linked me to Cunningham chains. Now that I know what a cunningham chain is, and I couldn't find an implementation in a good language, I need to implement it. Should I use Node.JS for it? I was thinking of using Haskell, but then I'd have to think to much. I think Node.JS will work better since it has better numerical support, and I can make a Node.JS website that uses socket.io to offload my prime computation to the background of clients using my website (essentially pay2view).
For example: One reason I thought haskell is suited for this is because you can make a lazy function that will stream out the values of each chain. Also runs on bare metal with no browser, but im not sure that's much of an advantage.
Computing Cunningham chains effectively requires Bignums.
Node.js uses V8 which can efficiently represent 31-bit signed integers. That isn't nearly big enough for Cunningham chains.
Haskell has architecture native integers and supports efficient Bignum calculation through GMP.
V8 does not yet have efficient Bignum support.
You are likely to get better performance from a Haskell implementation, particularly if you avoid using Strings entirely.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 6 years ago.
Improve this question
Has anyone seen a good comparison of parser generators' performance?
I'm particularly interested in:
1) recursive ascent parser generators for LALR(1) grammars;
2) parser generators which produce C/C++ based parsers.
Are you interested in how fast the parser generators run? Depends of the type of technology of the parsing engine it supports, and the care of the guy who implemented the parser generator. See this answer for some numbers about LALR/GLR parser generators for real languages: https://stackoverflow.com/a/14151966/120163 IMHO, this isn't very important; parser generators are mostly a lot faster than the guy using them.
If the question is, how fast are the generated parsers? you get different answers. LALR parsers can be implemented with a few machine instructions per GOTO transition (using directly-indexed GOTO tables), and a few per reduction. That's pretty hard to beat.