I am sorry to say that I ran out of time in preparing my entry for the Parallelized Parser Formula Interpreter.
I have nobody to blame except for myself in starting this project late.
I did make some good headway. I may finish it in any event and make my own test runs on the MTL system. My results will not count towards the contest. :(...
The strategy I am using is somewhat peculiar, perhaps someone else thought of this too.
I use a dual channel parallel_pipeline that has dual input and dual output data paths.
Path 1 - source code to compiled intermediary code with basic syntax checking and as precompilation of known variables and expressions to values. Residual incalculable expressions and output statements are written into an intermediary "compiled" interpreter code. Note, the output statements may be complete or the expressions are incalculable (but code inserted to attempt recalculation on later pass).
Path 2 - intermediary "compiled" code of one Path 1 output and an adjacent Path 1 output (either immediately preceding or following), this merges the two intermediary "compiled"buffers and in the process reduces nowcalculable expressions to valuesproduces a new "compiled" output code buffer, plus in the event that the two (or one remaining) compiled code buffers represents the front of the file, then the output statements are committed to the output buffer and stripped from the "compiled" code output buffer.
Each merge phase (of two adjacent buffers) is a reduction operation, the process continues (MUNGs along) until there is one compiled code output buffer, then that is finally passed through the compiled code interpreter, which if no syntax errors, will produce the remaining output (and report if there are any un-free'd variables).
Most of this is working. Currently tracking down a problem where a string(expression)that cannot currently be calculated (missing var's from earlier code not merged), is not producing the proper code to regenerate the missing parts of the statement for the next merge phase. (so close but so far from completion)
There is some redundancy involved with unresolvable expressions but presumably as merging progresses more and more expressions get resolved. This is somewhat like the "Snake eating its tail" type of process.
Will let you know how this goes.
It's been fun.
1) New system (Core i7-2600K) came in, wasted a day installing softwareand migrating code.
2) Working on house remodling (new shower).
3) Found bug in Parallel Studio Composer (variable& from prior closed scope getting mixed up with later same named variable reference in outer scope). This had me chasing my tail for a few hours. The function being called worked properly, but the results got placed into the wrong variable. Don't know if I can make a simple reproducer. If my "completed" project still exhibits the bug (conditional compile with/without work around) then that will be a reproducer.
4) Usual case of debugging taking much longer than anticipated.
5) Had to fix leak in plumming (3 times!).