By this I meant: when you design your app side effects free, etc, will F# code be automatically distributed across all cores?
相关问题
- F#: Storing and mapping a list of functions
- multidplyr : assign functions to cluster
- Multiplying a list of tuples by a tuple in F#
- Parallel for loop over range of array indices in C
- Multiplying a string in F#
相关文章
- How to use doMC under Windows or alternative paral
- FSharp.Data.JsonProvider - Getting json from types
- Signing an F# Assembly (Strong name component)
- Learning F#: What books using other programming la
- Parallel while loop in R
- Does gfortran take advantage of DO CONCURRENT?
- fsc.exe is very slow because it tries to access cr
- Using Parallel Linq Extensions to union two sequen
No it will not. You must still explicitly marshal calls to other threads via one of the many mechanisms supported by F#.
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.
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.
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.
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.
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!