1)As we know, there's no side-effect with map() and reduce(). Nowadays, we also have muti-core on cell phone. So is it more efficient to use them?
2)On the other hand, there's only 1 thread for js to execute on most of the browsers. Therefor map() and reduce() are prepared for server-side scripting?
It is easily overlooked, but the key to getting the benefits of MapReduce is to
A) Exploit the optimized shuffle. Often, your map and reduce functions can be implemented in a slow language, as long as the shuffle - the most expensive operation - is well optimized, it will still be fast and scalable.
B) Exploit the checkpointing functionality to recover from node failures (but hopefully, your CPU cores won't fail).
So in the end, map-reduce is actually neither about the map, nor the reduce functions. It's about the framework around it; which will give you good performance even with bad "map" and "reduce" functions (unless you lose control over your data set size in the shuffle step!).
The gains to be obtained from doing a multi-threaded map-reduce on a single node are fairly low, and most likely there are much better ways of parallelizing your shop for shared memory architectures than map-reduce...
Unfortunately, there is a lot of hype (and too little understanding) surrounding mapreduce these days. If you look up the original paper, it goes into detail about "Backup Tasks", "Machine Failures" and "locality optimization" (neither of which makes sense for an in-memory single-host use case).
Just because it has a "map" and a "reduce" doesn't make it a "mapreduce" yet.
It's only a MapReduce if it has an optimized shuffle, node crash and straggler recovery.