A lot to reply to: This article is not about Doug Lea. It is about the application service he wrote. Doug Lea is a fine scientist, educator, etc. Application programming is not his forte. The majority of code in the F/J framework is not from other but is one person. I love the JSR166 work. Use it all the time. Most of those classes are what is known as system programming. They are API's. The F/J framework is an application program. It belongs in the extensions framework, perhaps as javax.parallel. It is not the next chapter in the same book. It is a different book.
>Since the internal structure is so entangled with the calling client, there is almost no way to alter control variables The client code imbeds the framework in the initial call as a parameter. The framework then calls the client to do the processing. That is simple to program. But there is no way to get at the framework to change number of threads to use per call etc. A much better way is to separate the client call, server processing, and actual computation. Now the server is separately addressable to monitor performance, alter variables and save statistics. I had many conversations with Doug Lea last year. I did a proof of concept showing him that scatter-gather was a far superior algorithm than work-stealing. Just a simple load balancing increased throughput 5-7 times. Also separating the client from the server allowed better tuning (as above.) He pretty much ignored what I said. Eventually, I built the divide-and-conquer version of Tymeac from the embarrassingly parallel version. Now developers have a choice. The real test of scalability and performance comes when using these frameworks for applications that generate hundreds of thousands and millions of Tasks (like Scala.) Using work-stealing where Tasks all go into the same queue from which they were spawned and other threads have to go looking for work, is not the best approach. Let's be honest here. I did not mock academic research. Research and building on prior research is the scientific method. The problem is that research on work-stealing is for operating systems controlling work on CPU's. Application programming is a whole different beast. There is no academic research on work-stealing outside a controlled environment. Cilk and jCilk use a compiler and run time to control Tasks. Ed -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/mJy4f_2kaTEJ. To post to this group, send email to javaposse@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
