actor latency in parallel operations

With actors that use loop instead of receive, I've read they're
optimized to use as few thread switches as possible to avoid latency.
How is this regulated?

If one wanted to do a cheap version of parallelizing a map or just
mutating a list, would it make more sense to divide the map up in the
a few slices and combine them afterwords or launch a 1-to-1 number of
actors to handle every job? This is a assuming that each operation on
the list was fairly computationally expensive like computing a ray
intersection for a ray tracer, for instance. From what Martin wrote
in Programming in Scala, it seemed like these non-returning threads
were pretty fast and with enough work per element, it would be worth
the actor/thread management latency.

It seems like that's what is being done here...

http://debasishg.blogspot.com/2008/06/playing-around-with-parallel-maps-...

Josh