Continuing the discussion from Dan's crazy ideas #1 - Collaborative contest:
You thought I went away, that I was beaten back into the hole that I had emerged from! Stop the madness!
No! I will not back down! Madness ensues…
Concept
Join any decently large software project, and you will need to come to grips with parallel processing. Even if your project is single-process, single-thread, I guarantee that at least the discussion will come up.
Sidetrack to Dan’s silly little anecdote… I once worked on a very complex, multi-tiered behemoth of a project where each tier was under the control of a separate corporate organizational group… One day the walls came down, and all groups became one, and I found that one of the tiers was designed such that it spawned literally hundreds of threads at startup, and all but a few of them spent the vast majority of their life blocked on a pipe read… 
Okay, I’m back. So CG allows for the use of threads, but your code only has access to a single CPU, so multi-threaded code is never helpful.
Proposal
Simple enough. I think it would be cool to have a specific puzzle, or category of puzzle, or competition… what have you, that focuses on the use of parallel processing.
Disclaimer: Yes, I know that this will likely strain processing resources, and might make this proposal untenable.
Here are a few ideas for how this could be implemented:
-
Create a competition that is algorithmically intensive, as opposed to strategically intensive (i.e. STC rather than CB). Explicitly give entrants access to more than one CPU, and let them have at it.
-
Similar to #1, but as a puzzle. Create a puzzle that simply cannot be solved with a single thread in the allotted time. This would be hard to do. Multi-threading gives incremental gains, not order-of-magnitude, and so designing a puzzle that could, universally across languages and skill levels, be solved with two threads, but not with one might be impossible. It’s more likely with 4 or even 8 cores, but even then…
-
#2 revisited… Force the issue. Make the user implement an interface that will be called from multiple threads concurrently, and force them to somehow coalesce the results into a single, coherent output. This approach has the benefit that it could run just as effectively on a single virtual CPU. It has the drawback that it would require a whole new execution and I / O interface, different from all other puzzles. This might be prohibitive across the full spectrum of languages, and should probably be limited to a subset, if implemented.
Thoughts?
- danBhentschel