Difference between revisions of "GPU610/OctoPig"
(→Team Members) |
|||
| Line 5: | Line 5: | ||
# [mailto:jtrobins@myseneca.ca?subject=gpu610 Justin Robinson] | # [mailto:jtrobins@myseneca.ca?subject=gpu610 Justin Robinson] | ||
| − | [mailto:capilkey@myseneca.ca,jtrobins@myseneca.ca subject=gpu610 Email All] | + | [mailto:capilkey@myseneca.ca,jtrobins@myseneca.ca?subject=gpu610 Email All] |
== Progress == | == Progress == | ||
Revision as of 23:52, 20 February 2013
GPU610/DPS915 | Student List | Group and Project Index | Student Resources | Glossary
Contents
TBA
Team Members
Progress
Assignment 1
We began by profiling two things: a string-comparison algorithm, and a program which develops quasi-random visuals from an initial seed using a Turing Machine algorithm.
Justin's Findings
String comparison was not a good choice. If anything, it makes more sense to do string comparison in a serial fashion than in parallel. Comparing two strings of over 13,000 characters each in such a fashion as to force the algorithm to compare them all just barely results in a runtime of 0.001 seconds.
Chad's Profiling Findings
Chad, fill this in.
Analysis: Of our two selections, the choice to move forward with the pattern generator is clear.
Difficulties Met:
One apparent difficulty is the need to port the pattern-generator from Javascript into C in order to make use of CUDA.
Summary:
- String comparison is not an efficient use of parallel programming practises.
Resources:
