This demo effectively demonstrated the difficulty of coordinating a large number of "processing units", however it also added several interesting communication constraints in its row-by-row nature. The fact we could not yell to one another across the room was a realistic demo of why limiting communication paths between processing units can be necessary but also can hurt the performance of a system.
safari
During the demo we noticed that computation gets slower once the number gets large, i.e. 4 digit plus a 2 digit number, and I think this was a significant barrier in speeding up this task. So me and my friends we come up with this alternative solution: since we know the approximate avg age of the class, say 21, we could use 21 as the base line and carry out computation base on the avg. So each step we would need to pass on two numbers, the people we counted so far: k, and the sum of ppl's relative age to the avg: r. For example, say we process people with age: 19, 20, 21, 23, 20, we would get k = 5(five ppl) and r = -2 (-2 + -1 + 0 + 2 + -1). Then we compute the total age by total = k*21 + r. The advantage will make the calculation mainly in the single digit range.
I believe this method could speed up the process, but I have a question, how would this method be represented in a technical level. Maybe this is only a modification for the limited human computing power, and doesn't have any meaning for machines?
hofstee
@safari if you know the range of your data you can shrink memory footprint (sometimes). What you've said is essentially a basic version of data compression.
Allerrors
@safari I think compiler will convert some computation to shift operations to speed up the process. Also, at hardware level, some instructions have ability to compute big number operations in parallel.
Panda
We also observe that we are not using the processing ability of an entire row. If we could have parts of the row process simultaneously and then combine we might get better speedup if communication over head is not a lot.
This demo effectively demonstrated the difficulty of coordinating a large number of "processing units", however it also added several interesting communication constraints in its row-by-row nature. The fact we could not yell to one another across the room was a realistic demo of why limiting communication paths between processing units can be necessary but also can hurt the performance of a system.
During the demo we noticed that computation gets slower once the number gets large, i.e. 4 digit plus a 2 digit number, and I think this was a significant barrier in speeding up this task. So me and my friends we come up with this alternative solution: since we know the approximate avg age of the class, say 21, we could use 21 as the base line and carry out computation base on the avg. So each step we would need to pass on two numbers, the people we counted so far: k, and the sum of ppl's relative age to the avg: r. For example, say we process people with age: 19, 20, 21, 23, 20, we would get k = 5(five ppl) and r = -2 (-2 + -1 + 0 + 2 + -1). Then we compute the total age by total = k*21 + r. The advantage will make the calculation mainly in the single digit range.
I believe this method could speed up the process, but I have a question, how would this method be represented in a technical level. Maybe this is only a modification for the limited human computing power, and doesn't have any meaning for machines?
@safari if you know the range of your data you can shrink memory footprint (sometimes). What you've said is essentially a basic version of data compression.
@safari I think compiler will convert some computation to shift operations to speed up the process. Also, at hardware level, some instructions have ability to compute big number operations in parallel.
We also observe that we are not using the processing ability of an entire row. If we could have parts of the row process simultaneously and then combine we might get better speedup if communication over head is not a lot.