Re:How the Mill CPU does fork() in a single address space
by stcredzero on Thursday April 16, 2015 @01:44PM
(#9389528)
> The result of all of this is that fork() on a Mill requires a cache flush of dirty lines from the parent local space that is not required on (some) MAS machines, but has no other added overheads. The gain is that sharing between processes has byte granularity, not page granularity, and is vastly cheaper to use.
What are the implications for server processes? The cache flush seems like a good tradeoff for things like Apache. Extremely fast communication using RAM between processes running on multi-core machines looks like a good capability to have. Language runtimes like Erlang's could benefit from this tremendously.
(How about something like Golang, but with Erlang-like actors and the ability to declare that certain modules cannon contain functions with side effects? Without lazy evaluation, it wouldn't be great for processing large datasets, but it could be awesome for games. (Actors would be distributed amongst processes, each of which would have their own GC.))
What are the implications for server processes? The cache flush seems like a good tradeoff for things like Apache. Extremely fast communication using RAM between processes running on multi-core machines looks like a good capability to have. Language runtimes like Erlang's could benefit from this tremendously.
(How about something like Golang, but with Erlang-like actors and the ability to declare that certain modules cannon contain functions with side effects? Without lazy evaluation, it wouldn't be great for processing large datasets, but it could be awesome for games. (Actors would be distributed amongst processes, each of which would have their own GC.))