added timing-analysis.txt
git-svn-id: svn://anubis/gvsu@183 45c1a28c-8058-47b2-ae61-ca45b979098e
This commit is contained in:
parent
a702f7fffc
commit
36be2170a7
34
cs677/pa2/timing-analysis.txt
Normal file
34
cs677/pa2/timing-analysis.txt
Normal file
@ -0,0 +1,34 @@
|
||||
Times for big.seq and big.unk on mp:
|
||||
|
||||
Sequential: 5.33091 sec
|
||||
Threaded:
|
||||
num_threads time
|
||||
1 10.7522
|
||||
2 11.1476
|
||||
4 15.0832
|
||||
8 36.2662
|
||||
|
||||
The threaded version is slower in general than the sequential version because
|
||||
there is a lot more logic involved in each step for calculating the indices
|
||||
into the matrix and traversing it along diagonals instead of row-wise.
|
||||
With more threads, the threaded version also has to synchronize more (each of
|
||||
the threads does a barrier wait at the end of each step). Since some threads
|
||||
do not have much work, especially at the beginning and end of the algorithm,
|
||||
this leads to more time being taken doing the synchronization than the actual
|
||||
computation.
|
||||
|
||||
In contrast, when the "unknown" search sequence grows in length and the known
|
||||
database sequence shrinks, such that the two sequences are "more even" in
|
||||
length, then the threaded version does much better because there is less
|
||||
synchronization required compared to the amount of actual computation being
|
||||
done:
|
||||
|
||||
Times for more-even.seq and more-even.unk on mp:
|
||||
|
||||
Sequential: 1.34995 sec
|
||||
Threaded:
|
||||
num_threads time
|
||||
1 10.0506
|
||||
2 4.26101
|
||||
4 2.7733
|
||||
8 2.64885
|
Loading…
x
Reference in New Issue
Block a user