[gwt-contrib] Re: RR : Pluggable CompilePerms workers
I spent quite a bit of time trying out this new permutation worker framework (mostly spent stepping through it in my debugger, as I was having issues). Here are my thoughts: 1). The mechanism for designating the number of threads or processes needs to be cleaned up or rethought. The parameter -localWorkers N ends up spawning 1 ThreadedPermutationWorker and N-1 ExternalPermutationWorkers. This is counter-intuitive, because when I set something to N, I'm expecting to see N homogeneous objects. That's because if you don't specify a value for gwt.jjs.permutationWorkerFactory, the default is to start creating threaded workers up to maxThreads and use external workers for the rest. I have a dual-core CPU, so I wanted to use 2 threads. I eventually figured out that the way to accomplish this is to either a). set -Dgwt.jjs.maxThreads=2 *and* -localWorkers 2 simultaneously, or b). set - Dgwt.jjs.permutationWorkerFactory=com.google.gwt.dev.ThreadedPermutationWorkerFactoryand -localWorkers 2 A better way of managing this would be to have two command-line parameters, nProcesses and n nThreadsPerProcess. 2). I couldn't get ExternalPermutationWorkerFactory to work: java.net.ConnectException: Connection refused: connect at com.google.gwt.dev.CompilePermsServer.run (CompilePermsServer.java:243) 3). Finally, I'm sorry to say this, but this framework is mostly useless if you have fewer than 8 cores and more than one module to compile. There is very little performance gain when I compile with 2 threads instead of 1 (only 10% per module on a dual-core CPU with 5 permutations per module). Although the permutations can now be compiled using possibly more than one thread, the modules are still processed sequentially. If you have more than one output module (and I suspect most developers for whom compiler speed is an issue fall into this category), then it's much faster to run the compiler in parallel (i.e. invoke multiple instances of the complier with 1 module each, instead of one compiler process with a list of modules). This gives you a 100% boost on a dual-core CPU. I've been doing this using the ForTask from ant- contrib for the past half year and it halved my build time. In other words, the task of compiling modules is embarrassingly parallel, but the the task of generating permutations within a module doesn't seem to be so. So basically, as much as this new framework looks cool, it's totally useless to me when I have to build more than one module. If I had a computer with 2 quad-core CPUs (like Bob ;) ), on the other hand, I might spawn 2 compiler instances with 4 threads each. Some food for thought here - perhaps you should think about using the external workers for modules and threads for permutations. Alex On Jan 21, 6:45 pm, Alex Epshteyn alexander.epsht...@gmail.com wrote: This stuff looks great, guys. Is there any chance of actually setting up a distributed build cluster using this code? Back when I had an older laptop, I've thought about the idea of spawning one or more EC2 instances to do builds. Now, with a top of the line laptop, I was happy for a while, but I still only have 2 cores, and build times are starting to bother me again. On Nov 24 2008, 12:00 pm, Lex Spoon sp...@google.com wrote: On Thu, Nov 20, 2008 at 8:58 PM, Scott Blum sco...@google.com wrote: - We ended up going with Lex's ThreadPoolExecutor stuff. Mainly because he was physically here, and I think both of the TPE-based implementations suck. Well, we eliminated TPE itself. However, we went with message-passing coordination rather than checking multiple counters and queues and/or checking the interrupted states. -Lex --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RR : Pluggable CompilePerms workers
On Thu, Nov 20, 2008 at 8:58 PM, Scott Blum [EMAIL PROTECTED] wrote: - We ended up going with Lex's ThreadPoolExecutor stuff. Mainly because he was physically here, and I think both of the TPE-based implementations suck. Well, we eliminated TPE itself. However, we went with message-passing coordination rather than checking multiple counters and queues and/or checking the interrupted states. -Lex --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RR : Pluggable CompilePerms workers
Thanks, Bob. List, Bob and I looked at this together. In general it looks great. Things I want to do: 1. Ponder the overall strategy for starting up worker threads and communicating with them. It looks odd to me to use the interrupted thread state to communicate whether workers should shut down, but maybe there's nothing better. 2. Check how Scala deals with finding the Java VM to run. I think it's the same way as is used here. Things for you to do, Bob, by my notes: 1. When starting a permutation daemon, give it a cookie to send back on the socket it uses to connect to the worker manager. That way, the manager knows it is talking to a daemon it itself spawned, and not some attacker. 2. When reading stdout and stderr from a spawned thread, make two reader threads instead of just one. This improves the hypothetical case where stdout has a lot of output but stderr has nothing, or vice versa. 3. (maybe) Add a system property for the arguments to pass to Java when starting it. This would be an escape hatch in case copying the current JVM's arguments does not work in some weird context. Also, there's a debate around the office about calling System.gc(). It can speed things up in theory, but it can decrease performance heavily in some contexts. So, it's a bit of a landmine at the best of times. Maybe we should avoid using it until we have a better evidence that it improves things. -Lex --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RR : Pluggable CompilePerms workers
On Thu, Nov 20, 2008 at 2:44 PM, Lex Spoon [EMAIL PROTECTED] wrote: Things for you to do, Bob, by my notes: Also: 4. Call accept() within the worker thread, not in the main thread that creates all the workers. That should speed things up a little, allowing the first JVM that starts to go ahead and start working, without waiting for the last JVM to start. -Lex --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RR : Pluggable CompilePerms workers
I checked about java.home, and as far as I can tell the patch is doing the right things. I messed around with the threading logic, and did manage to come up with something I think is a little easier to reason about. It's not a huge advantage, but I get paranoid about concurrency bugs, so every little simplification helps. Instead of each task being a manager that itself reads from a queue of permutations to work on, each task is itself a permutation. There is a separate list of workers that are not currently in use. Advantages are: there is no more explicit use of synchronized, no more wait and notify calls, and no more need to use the interrupted flag on Java threads. Let's get this all merged together, now. Lex --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~--- PermutationWorkerFactory.java Description: Binary data diffFromBobs.patch Description: Binary data
[gwt-contrib] Re: RR : Pluggable CompilePerms workers
w00t, we committed this as r4145! We did make a few changes to it: - Passing serialized ASTs around is gimpy, we just pass the UnifiedAst; it can handle memory management internally. This actually allows the main process to reuse the original Ast. - We flipped things around such that the caller actually passes a corresponding set of result files into the PWF. This prevents having to do the temp-file-then-copy trick with CompilePerms. I still want to go back at some point and implement the generic file-backed serializable thing concept which would make this even cleaner. - Fixed a few bugs. - We ended up going with Lex's ThreadPoolExecutor stuff. Mainly because he was physically here, and I think both of the TPE-based implementations suck. :) Tomorrow we need to check the build machine for a successful 1.6 build, and then merge up to trunk so you can merge in SOYC. Scott --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RR : Pluggable CompilePerms workers
On Fri, Nov 14, 2008 at 12:08 PM, BobV [EMAIL PROTECTED] wrote: The attached patch allows the CompilePerms phase of the compile to be executed via pluggable strategies. Is this for trunk or 1.6? -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
