Wednesday, October 13, 2010

IDF 2010 Video Interviews Now Available

My ISN-TV interview from September's IDF in San Francisco is now available at:

http://software.intel.com/en-us/blogs/2010/10/11/idf-2010-video-interviews-now-available-jim-dempsey-gaston-hillar-james-reinders-and-softtalk-bloggers-sean-mcmanus-and-lauren-bishop/

Additional, the .PDF composition of my 5-part article series on ISN Parallel Programming Community can be found at:

http://www.quickthreadprogramming.com/Superscalar_programming_101_parts_1-5.pdf

Jim

Thursday, June 10, 2010

Version 2.0 Beta Program

My silence over the last few months is due to overwork in preparing a version update to QuickThread. Version 2.0 will include support for running on Linux.

Major internal changes were made to accommodate a single source QuickThread scheduler, with a few conditional compilation directives, that works for both Windows and Linux operating systems.

Preliminary testing has been performed on Ubuntu 10.0 and with g++ 4.5 (pre-release). g++ 4.4 works too however the c++0x Lambda functions are not available in g++ 4.4.

Externally your programs will run with little or no change other than being required to be re-compiled.

Exposed API difference mainly concern a different layout for the qtControl structure and some member functions called by the templates.

The internal changes relate to using pthreads on Linux to establish the QuickThread tread pool, while permitting Windows native threads on Windows.

On Linux the maximum number of compute class threads is 1024. This can be expanded but would require a recompilation of the libQuickThread.a library.

Using Windows native threads (not on Wndows 7) the upper compute class thread count is 64. If interest develops for more than 64 threads on Windows 7 then this issue can be addressed at that time.

For those interested in participating in the beta program, please contact me via my email address on www.quickthreadprogramming.com

Jim

Thursday, January 28, 2010

New blog posts on ddj.com

I am writing today to mention that two new blog posts are available on www.ddj.com/go-parallel relating to using a QuickThread two stage parallel pipeline to improve the performance of the input end and output end of an application (as opposed to 3 stage design.

The typical 3-stage pipeline is:

MyPipelineIOContext pio;
pio.Init(your init args here);
qtPipeline< MyPipelineIOContext, MyPipelineBuffer > pipeline;
pipeline.addPipe(InputPipe);
pipeline.addPipe(DoWorkPipe);
pipeline.addPipe(OutputPipe);
pipeline.run(&pio);
pipeline.WaitTillDone();

The 3-stage pipeline works quite well for most applications. However, there are certain classes of applications where a single linear pipeline is unsuitable. One such example was referenced in the ddj.com/go-parallel blog. For this you might find sandwidching your work phase between two 2-stage pipelines:

// 2-stage pipeline to suck-in and prep data
MyInputPipelineIOContext pio_in;
pio_in.Init(your init args here);
qtPipeline< MyInputPipelineIOContext, MyInputPipelineBuffer > pipeline_in;
pipeline_in.addPipe(InputPipe); // I/O
pipeline_in.addPipe(DoInputPrepWorkPipe); // compute
pipeline_in.run(&pio_in);
pipeline_in.WaitTillDone();
// input complete (back to serial code)

// start work (which has parallel constructs)
DoWorkOutsideOfPipeline();
// done with work

// use 2-stage pipeline to output results
MyOutputPipelineIOContext pio_out;
pio_out.Init(your init args here);
qtPipeline< MyOutputPipelineIOContext, MyOutputPipelineBuffer > pipeline_out;
pipeline_out.addPipe(DoOutputPrepWorkPipe); // compute
pipeline_out.addPipe(OutputPipe); // I/O
pipeline_out.run(&pio_out);
pipeline_out.WaitTillDone();

The prep work for input might consist of converting ASCII text input into binary format. The prep work for output migh be converting binary format to ASCII text. Although you are free to use as you see fit.

Jim