Updated, see below!
I have heard and read that C++0x allows an compiler to print \"Hello\" for the following snippet
#include
I think the issue could perhaps best be stated, as "If a later piece of code does not depend on an earlier piece of code, and the earlier piece of code has no side-effects on any other part of the system, the compiler's output may execute the later piece of code before, after, or intermixed with, the execution of the former, even if the former contains loops, without regard for when or whether the former code would actually complete. For example, the compiler could rewrite:
void testfermat(int n) { int a=1,b=1,c=1; while(pow(a,n)+pow(b,n) != pow(c,n)) { if (b > a) a++; else if (c > b) {a=1; b++}; else {a=1; b=1; c++}; } printf("The result is "); printf("%d/%d/%d", a,b,c); }
as
void testfermat(int n) { if (fork_is_first_thread()) { int a=1,b=1,c=1; while(pow(a,n)+pow(b,n) != pow(c,n)) { if (b > a) a++; else if (c > b) {a=1; b++}; else {a=1; b=1; c++}; } signal_other_thread_and_die(); } else // Second thread { printf("The result is "); wait_for_other_thread(); } printf("%d/%d/%d", a,b,c); }
Generally not unreasonable, though I might worry that:
int total=0; for (i=0; num_reps > i; i++) { update_progress_bar(i); total+=do_something_slow_with_no_side_effects(i); } show_result(total);
would become
int total=0; if (fork_is_first_thread()) { for (i=0; num_reps > i; i++) total+=do_something_slow_with_no_side_effects(i); signal_other_thread_and_die(); } else { for (i=0; num_reps > i; i++) update_progress_bar(i); wait_for_other_thread(); } show_result(total);
By having one CPU handle the calculations and another handle the progress bar updates, the rewrite would improve efficiency. Unfortunately, it would make the progress bar updates rather less useful than they should be.