User Tools

Site Tools


haas:spring2024:comporg:projects:pnc0

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
haas:spring2024:comporg:projects:pnc0 [2024/03/13 13:10] – [PNC1] wedgehaas:spring2024:comporg:projects:pnc0 [2024/04/10 21:09] (current) – external edit 127.0.0.1
Line 14: Line 14:
   * performs a brute force/"trial-by-division" process on a range of values, 2-N   * performs a brute force/"trial-by-division" process on a range of values, 2-N
     * the values for N are some sufficient quantity still small enough to fit within an integer     * the values for N are some sufficient quantity still small enough to fit within an integer
-    * the values for N will have some relationship (powers of 2, powers of 10/magnitudes) that ideally can be computed via some loop/equation (ie 100020004000800016000, etc.)+    * the values for N will have some relationship (powers of 2, powers of 10/magnitudes) that ideally can be computed via some loop/equation (ie 102420484098819216384, etc.)
     * the values for N have some sufficient quantity large enough where its upper set values will take some amount of time to compute (fast enough to have some relatable value, not to exceed 16 seconds)     * the values for N have some sufficient quantity large enough where its upper set values will take some amount of time to compute (fast enough to have some relatable value, not to exceed 16 seconds)
     * for each value of N:     * for each value of N:
-      * display the number of primes identified (2-N) +   display that N/upper bound 
-      * display the amount of time taken to do the total computation for that value of N+      * tally: display the number of primes identified (2-N) 
 +      * display the amount of time taken to do the total computation for that value of N, out to 3 decimal places
       * display each N value and result in an arrangement on the screen that can be clearly identified and read by the viewer       * display each N value and result in an arrangement on the screen that can be clearly identified and read by the viewer
-  * timing should go out, as reasonable, to a few decimal places, but should be consistent across all attempts. +  * timing should go out, as reasonable, to a few decimal places, and should be consistent across all attempts. 
-    * for accuracy, each run should be performed at least 4 times, and the average runtime taken is what is used in the final results. +    * timing is on the computational process only, not the display of results.
-        * timing is on the computational process, not the display of results.+
   * create a graph (using some external tool) that plots the performance of the C and assembly implementations working on identical workloads of this brute force algorithm according to the various N's and the time it took. Share your graph of your results on the class discord and on the project documentation page.   * create a graph (using some external tool) that plots the performance of the C and assembly implementations working on identical workloads of this brute force algorithm according to the various N's and the time it took. Share your graph of your results on the class discord and on the project documentation page.
     * a line graph is the suggested best candidate     * a line graph is the suggested best candidate
-  * the assembly version is to be done entirely by hand, and make zero use of C API functions (possible exception being output of floating point values). Just the usual in/out stuff we've been doing.+  * the assembly version is to be done entirely by hand, and make zero use of C API functions. Just the usual in/out stuff we've been doing.
   * this will not be an interactive program: it starts up, does its thing, outputs it results, then halts.   * this will not be an interactive program: it starts up, does its thing, outputs it results, then halts.
-  * this brute force implementation is meant as our baseline. As such, it should not contain any optimizations or attempted improvements. As we progress through pnc1 and pnc2, these variants should be the least efficient. This is important, to allow us to realize the impact of various improvements we will be making in those upcoming projects.+  * this brute force implementation is meant as our baseline. As such, it should not contain any optimizations or attempted improvements. As we progress through pnc1 and pnc2, this base implementation should be the least efficient. This is important, to allow us to realize the impact of various improvements we will be making in those upcoming projects.
  
 =====REFERENCE===== =====REFERENCE=====
Line 33: Line 33:
  
 ====PNC0==== ====PNC0====
 +
 +===C implementation===
 {{:haas:spring2024:comporg:projects:pnc0runtime.png|}} {{:haas:spring2024:comporg:projects:pnc0runtime.png|}}
  
- 
-====PNC1==== 
- 
-===C implementation=== 
-{{:haas:spring2024:comporg:projects:pnc1runtime.png|}} 
 =====EDIT===== =====EDIT=====
 You will want to go [[/notes/comporg/spring2024/projects/pncX|here]] to edit and fill in the various sections of the document: You will want to go [[/notes/comporg/spring2024/projects/pncX|here]] to edit and fill in the various sections of the document:
Line 90: Line 87:
 *:pnc0:graph produced from timing data produced [26/26] *:pnc0:graph produced from timing data produced [26/26]
 *:pnc0:graph posted to discord and documentation page [26/26] *:pnc0:graph posted to discord and documentation page [26/26]
-*:pnc0:timing data is the average of multiple attempts [26/26]+*:pnc0:timing data is the taken out to 3 decimal places [26/26]
 </code> </code>
  
haas/spring2024/comporg/projects/pnc0.1710335423.txt.gz · Last modified: 2024/03/13 13:10 by wedge