Yes, no doubt this is all true.
in reply to Re: Could there be ThreadedMapReduce (and/or ForkedMapReduce) instead of DistributedMapReduce?
in thread Could there be ThreadedMapReduce (and/or ForkedMapReduce) instead of DistributedMapReduce?
But my point is that by hiding my parallelization code in a threadedreduce, and putting the "meat" of my program in a "function builder" such as grepbuilder / mapbuilder / urlgrabbuilder -- that relies on threadedreduce or nonthreadedreduce -- I make experimentation easier, and maintenance easier.
I also write code that is easily portable to running on more than one thread, or more than machine. Just change one line, and see if you get an improvement. If there's no improvement, or things actually get worse, switch back to nonthreadreduce / nondistributedreduce.
These days, feels to me like I'm always second guessing myself with my thread code, rather than concentrating on the meat of my program.