By this I meant: when you design your app side effects free, etc, will F# code be automatically distributed across all cores?
+1
A:
No it will not. You must still explicitly marshal calls to other threads via one of the many mechanisms supported by F#.
JaredPar
2009-03-25 17:52:29
+1
A:
No, I'm pretty sure that it won't automatically parallelise for you. It would have to know that your code was side-effect free, which could be hard to prove, for one thing.
Of course, F# can make it easier to parallelise your code, particularly if you don't have any side effects... but that's a different matter.
Jon Skeet
2009-03-25 17:53:01
Doesn't the type system of F# distinguish between pure and impure functions? So it shouldn't be that hard to know an operation was side-effect free.
Daniel Earwicker
2009-03-25 18:02:26
Thanks Jon. By proving you mean, you have to use stuff like Contracts?
Joan Venge
2009-03-25 18:04:36
I'm not aware of that distinction, but that's a long way from saying it isn't there. Presumably that cuts out any interaction with the framework though - and what about exceptions?
Jon Skeet
2009-03-25 18:05:54
@Joan: I'm saying that for it be able to automatically parallelise would be very hard, and probably wouldn't be helpful in as many situations as careful manual parallelisation with useful libraries and language features to make it easier.
Jon Skeet
2009-03-25 18:07:39
Yes, I guess one day they're going to have to attribute all the methods in the BCL to indicate whether they are pure... quite an undertaking.
Daniel Earwicker
2009-03-25 18:08:55
@Earwicker: Would it really be that hard? Suppose you start with a subset of "impure" functions based on: 1. they assign to fields, or 2. they directly reference unsafe or unmanaged code. Any other methods depending on that set are likewise impure. The rest are pure. What am I missing?
Daniel Pratt
2009-03-25 20:22:44
No, F# currently does not distinguish pure functions in the type system.
MichaelGG
2009-03-25 23:49:59
@Daniel, this is complicated by the fact even pure closures are going to have fields that get set. Add in versioning (since the type stays the same), and you have quite a problem...
MichaelGG
2009-03-25 23:54:03
It'd be much easier if the compilers emitted purity annotation into their code to allow an analysis tool to understand certain constructs and assume purity.
MichaelGG
2009-03-25 23:56:35
@MichaelGG: You're point about versioning is a good one. It does complicate things somewhat. As far as "pure" closures setting fields? I'm not convinced. I think of a pure function as one that has no side-effects. Setting a field is changing some external state, which is a side-effect.
Daniel Pratt
2009-03-26 14:22:55
+1
A:
My understanding is that it won't but Parallel Extensions is being modified to make it consumable by F#. Which won't make it automatically multi-thread it, should make it very easy to achieve.
JoshBerke
2009-03-25 17:53:17
+1
A:
Like the others mentioned, F# will not automatically scale across cores and will still require a framework such as the port of ParallelFX that Josh mentioned.
F# is commonly associated with potential for parallel processing because it defaults to objects being immutable, removing the need for locking for many scenarios.
Richard Szalay
2009-03-25 18:00:22
+10
A:
No, I'm afraid not. Given that F# isn't a pure functional language (in the strictest sense), it would be rather difficult to do so I believe. The primary way to make good use of parallelism in F# is to use Async Workflows (mainly via the Async module I believe). The TPL (Task Parallel Library), which is being introduced with .NET 4.0, is going to fulfil a similar role in F# (though notably it can be used in all .NET languages equally well), though I can't say I'm sure exactly how it's going to integrate with the existing async framework. Perhaps Microsoft will simply advise the use of the TPL for everything, or maybe they will leave both as an option and one will eventually become the de facto standard...
Anyway, here are a few articles on asynchronous programming/workflows in F# to get you started.
Noldorin
2009-03-25 18:03:55
+1
A:
Well, you have your answer, but I just wanted to add that I think this is the most significant limitation of F# stemming from the fact that it is a hybrid imperative/functional language.
I would like to see some extension to F# that declares a function to be pure. That is, it has no side-effects that are not denoted by the function's type. The idea would be that a function is pure only if it references other "known-pure" functions. Of course, this would only be useful if it were then possible to require that a delegate passed as a function parameter references a pure function.
Daniel Pratt
2009-03-25 18:13:01
+6
A:
F# does not make it automatic, it just makes it easy.
Yet another chance to link to Luca's PDC talk. Eight minutes starting at 52:20 are an awesome demo of F# async workflows. It rocks!
Brian
2009-03-25 20:16:48
+1
A:
On purity annotations: Code Contracts have a Pure attribute. I remember hearing the some parts of the BCL already use this. Potentially, this attribute could be used by parallellization frameworks as well, but I'm not aware of such work at this point. Also, I' not even sure how well code contacts are usable from within F#, so a lot of unknowns here.
Still, it will be interesting to see how all this stuff comes together.
Kurt Schelfthout
2009-03-26 10:42:45