Quote from: jedi95 on February 15, 2012, 04:44:26 AM

Quote from: Diapolo on February 14, 2012, 05:39:08 PM

Interesting, seems like the fix was simply to remove the ", is_blocking=True" parameter I had in my init on both cl.enqueue_ commands and re-enable the use of self.commandQueue.finish().

Edit: Another strange observation is, that Phoenix seems faster (is quicker at the highest rate) without verbose = true ... does that make any sense???

Dia

Glad you got that figured out.

I also traced the root of the PyOpenCL issues with 2011.1 and 2011.2. The PyOpenCL commit that introduced the problem is 13d825712c57598085445b748084f9257b14981f "Default is_blocking to True."

The fix is to simply set is_blocking=False. At first glance it is very confusing as to why this would cause getting work to take much longer. Getting work is performed in the main thread and the kernel uses a separate thread for mining. The root problem is Python's GIL. (Global Interpreter Lock, see here for details) Your performance issue with is_blocking=True was most likely also due to the GIL.

Anyway, as a result of this being resolved future Windows builds of Phoenix will use the latest PyOpenCL.

Very nice, now that are pretty good news

... when can we test the next release?
Thanks for your hard work on that long standing issue jedi!

Dia