One of the things that intrigues me about Haskell is marrying functional programming to Haiku’s excellent threading and multi-core support. It has been said that one of the most difficult aspects of programming for Haiku is dealing with thread synchronization issues: race conditions, semaphores, variables in correct scope, deadlocks, etc. Haskell shows promise is addressing those difficulties, at least in theory.
Actually the very document you cite goes to some trouble to tell you…
One of the most important lessons about dealing with tricky problems is that you should avoid them when possible. It is unfortunate then that Haiku chooses to preserve design choices in BeOS which force programmers to solve unnecessarily tricky problems.
I don’t know if I’m ready to give up on the BeOS concurrency model, but it really doesn’t have that much to do with Haskell. If you’re working with the BeOS multithreaded application library - BWindow etc. - you’re using the same API, makes no difference whether you’re writing in C++ or Haskell. If you’re working with general purpose concurrency, as illustrated in the article cited above, I’m sure Haskell is head and shoulders above C++, but it makes no difference what platform you use, as long as it supports POSIX pthread functionality.
In fact, in that article, they’re using “green” threads - forkIO spawns a control thread that’s managed by the runtime, as opposed to a POSIX thread managed by the kernel (forkOS.) That’s much lighter weight, and that’s where all the talk about high performance concurrency in Haskell is coming from.
The runtime spawns several OS threads, but they rather discourage you from using forkOS to make your own. What Haiku brings to threads, the Haskell world has no use for. We’ll be lucky as long as it even works.
I really like Clojure’s Concurrency Model. Functional Programming and immutability bring some aspects to the table. But I’m uncertain how well would that play in terms of a OS.
One of the most important lessons about dealing with tricky problems is that you should avoid them when possible. It is unfortunate then that Haiku chooses to preserve design choices in BeOS which force programmers to solve unnecessarily tricky problems.[/quote]
So if something has advantages “insert counter argument here” and its tricky, it shouldn’t be done becuase its difficult, or maybe even gasp, requires proficiency ?
boy that sure as hell sounds like a copout to me. I don’t know how the world would ever get beyond the earth is flat stage if someone didn’t take on the tricky task of findings its curvature.
Or inventing algebra, or trigonometery, etc etc etc.
Sounds like you’ve already decided to fial, before you have begun.
Let me restate my original point. My point was that Haiku is innovative for its support of multithreading in the heart of the OS. This is done through use of BLooper, bemaphores, as well as the standard support for semaphores, pthreads, and microkernel support for multiple cores.
Making good use of multiple cores is a hot topic and getting hotter with the release of AMD’s BullDozer which will have 8 cores per chip. There remains a lot to be done in this field.
Haiku could be an excellent academic research tool for upper level computer science classes, PhD research, Master’s thesis, and more. Adding more tools for functional programming: Haskell, Erlang, OccamPi, and MPI, Intel TBB, etc. These are just some of many tools for research in this area.
This kind of research could happen even with only an Alpha release of Haiku and Haskell.
[quote=NoHaikuForMe]It seems like thatguy missed two vital words.
[quote=NoHaikuForMe]
One of the most important lessons about dealing with tricky problems is that you should avoid them when possible.[/quote][/quote]
No, I ignored them. Most of the computing problems we face today are not untricky. Especially given the hardware in use. Its not going to change.
so put on the big boy pants Peter B and suck it up and get on with your life, crying like a girl isn’t going to make you write better applications. Sitting down and writing them will however.
Well, I’m afraid Be Inc engineers didn’t agree with you:
[quote=George Hoffman]
What Be engineers are best at is taking some problem which is laughably easy to solve and making it complicated enough to interest us.[/quote]
… and the result of this philosophy was that for example if you want to create two windows, they each require their own separate thread and message loop which means you now need to solve a tricky concurrency problem to do something which is otherwise perfectly simple.
In some places Haiku cleaned up these goofs from the BeOS days. For example by moving the network stack inside the kernel they were able to consolidate select() and avoid lots of hacks where threads exist only to block on a single resource. But not everything was cleaned up, some of that philosophy of “making it complicated” survives.
I agree that the BeOS/Haiku approach is interesting, if only because it’s relatively uncommon, but of course (apart from someone’s bizarre trolling mission here) we’re talking about Haskell, where if you follow my discussion above, concurrency performance is about multiple processor cores, with approximately one POSIX thread each. Can you say more about the relevant features of Haiku’s support for multiple processor cores that might be of academic interest? I know the folks who work on GHC compiler/runtime internals are keenly interested in this kind of thing, so if we’re sitting on something here they might be excited to hear about it (and of course that couldn’t hurt our prospects of a fully working GHC on Haiku.)
I can’t speak to specifics other than that the multi-core support is in the hybrid-microkernel, it’s open source, and it’s not Linux, and it mostly works on old and new PCs. This is a pretty good start for someone who has an academic project and needs an interesting platform on which to do it.
I myself have done some very rudimentary SMP programming, as proof of concept,
[quote=AndrewZ]
So, just out of curiosity, what restricts Haskell to a single thread per core? It’s just designed that way?[/quote]
It isn’t restricted, it’s just more efficient that way by a considerable margin. You can have as many OS threads as you want (or must have, to support BeOS API constructs like BWindow), but for a compute-heavy problem you would typically be advised to use “green” threads and let the runtime map them to per-processor OS threads.
Sorry to dig up an ancient thread, but I am wondering if there are any recent developments regarding the Haskell GHC compiler on Haiku. I was wanting to port over a Haskell program to Haiku, only to discover that we don’t have a compiler and the compiler is self-hosting, so I am pretty far out of my league here.
The problem I ran into on X86_64 is that the compiler produces the assembly instructions that create the wrong redirections, to be linked with -shared as Haiku does. Like, where we get the apparently required
R_X86_64_REX_GOTPCRELX relocation from
GHC generates code like leaq base_DataziTuple_swap_closure(%rip),%rbx
… which is R_X86_64_PC32.
Don’t let me give you the idea I know what any of this means. The people responsible for this at GHC headquarters didn’t really seem to either. I gave it up as a bad job. There are some nice things about Haskell, but not enough to make it worth putting up with GHC, and honestly I think I’m writing better code in OCaml.
On 32 bits, you can make it up to fairly recent version 8 compilers, albeit with a good deal of effort. (What we have is something like 7.83.)
Doesn’t Haskell use its own linker or does it have a LLVM backend to generate its binaries? Either way, at least in the case for the x86_64 Golang port which uses its own compilers and linkers, it isn’t possible to create binaries with functions that have R_X86_64_PC32 relocations. i.e non position executable binaries.
I could be wrong but treating all external symbols with R_X86_64_REX_GOTPCRELX or similar with external linking works. I’m not sure on the status of Haskell, but this appears to be a similar situation with the Golang port given that other issues still come up related to this like broken internally linked binaries and inproper TLS (thread-local storage) initialization in the runtime.
I don’t know the specific state of TLS in our runtime loader other than Initial/Local executable (static TLS) being unsupported or the internals are but these are the sort of issues that get in the way of bootstrapping some languages here.
There may be alternatives, but the way it has been working, they use “as” and “ld” out of the gcc tool chain. Of course this happens on 32-bit with a cross compiler, because GHC can’t compile itself on an unsupported platform.
As I was saying above, the answer from where I was sitting seemed to be the choice of instructions and registers, that you use to for example pull up an entry point address. No doubt one could learn how all that works, find out where GHC is making these decisions and fix it. I don’t think it’s worth it, but perhaps someone will some day.
