Computer Systems Programming
ECE454, Fall 2025
University of Toronto
Instructors:
Ashvin Goel,
Ding Yuan
ECE454 Lab 2 FAQ
Q: I have had trouble with image generation. Can you clarify how the image should be generated using gimp?
A: A failure to export the image in an appropriate format specification may generate seg-faults.
a. Create new image using gimp
File->New
b. Specify Pixel Numbers (Must be square)
Image size: 2345x2345
c. Create some "object"
color the image
d. Export as bitmap image
test.bmp
e. Adjust the correct options
click on "do not write color space information"
24 bits
export
Q: Can we use #include<..>? Can we include other libraries?
A: You can include any header files that work with the current CMake setup. Third-party libraries won't work since you would need to modify the cmake files to link them and we don't allow changing the cmake files in this lab.
Q: Can we modify implementation_driver in any way? I will still call verifyFrame every 25 frames of course.
A: Yes. Note that you need to keep the function declaration (function name, return value, parameters) the same and call verifyFrame every 25 frames. As long as your implementation.c compiles without modifying anything else in the project you are most likely fine.
Q: My submission compiles fine on the UG machines but fails with the automarker. How can I debug this issue?
A: It is possible that your code is not strictly C. For example, you may have changed your cmakefile. The automarker enforces the C99 standard rather than GNUC (which is more relaxed).
Q: My current implementation with a CSV file that has 500 random moves and a lab1.bmp file of size 1250x1250 passes on the UG machine but fails with the automarker on frame #2. How can I debug this issue without seeing the input file used by the automarker?
A: Make your own CSV file that tests all possible orientations of the image (there is a very small number of these orientations). Also use an asymmetrical image (for example add different colours to lab1.bmp).
Q: Can we use pthreads?
A: Based on past experience, multi-threading isn't suitable for lab2 and students who tried multi threading didn't get much better results than a single threaded solution. In addition, the focus of this lab is optimization for memory access instead of multi threading. You will have a chance to optimize the program with multi threading in later labs. Hence, please don't use multi threading for this lab.
Q: Can we use xmmintrin?
A: Yes.
Q: Can we change the compiler optimization flag?
A: No. Our makefile uses -O0 optimization. You are not allowed to change this flag or compile your code using any other compiler optimization level.
Q: Why use -O0 for the compiler optimizations?
A: For this assignment, we expect you to perform simple compiler optimizations manually and thus we do not allow using compiler optimizations.
For an alternate view, see https://stackoverflow.com/a/32001196
Q: How much DRAM does the server machine have?
A: 16GB, 10GB free.
Q: When will you publish the threshold speedup?
A: The threshold speedup will be announced on Piazza by the end of 1st week based upon the results of submissions in the first week.
Q: Are the input files used by the automarker publicly available?
A: We used different automarker input files every year and they are not published anywhere. Do not ask TAs for any hints on the input values. Other than the input files, there are no other "hidden" test cases.
Q: How does the automarker measure the time our function implementation_driver uses? Does verifyFrame time gets included? Does our program startup time (e.g. stack memory allocation) get included?
A: You are welcome to look at the various source files to see how we time your code.
Q: How should I go about testing my implementation?
A: The automarker uses large inputs and a large image. Test your solution with an hypothetical input that runs for about 15 minutes on the reference solution.
Don't submit broken or slow solutions. It slows down the automarker and you won't get any feedback where it crashes. This is to done on purpose to prevent student taking advantage of the automarker.
Q: Does the automaker show the results of my last submission or my best submission?
A: The last submission. We suggest using git or other versioning methods to ensure that if your last submission is slower than your best submission, then you can revert back the sources to your best submission and submit again. Note that slight variations in speedup for the same submission are possible.
Q: Will you run the automarker for all students after the deadline?
A: No. The results you see with the automarker for your last submission before the deadline are your final results.
Q: Can you give any hints?
A: Think hard about why the reference solution is slow. You should consider using compiler optimization techniques in your implementation. Don't perform premature optimization (readability is important).
Always improve your high-level algorithm first. You should always convince yourself that the algorithm is optimal before you dive into any low-level optimization. In the reference implementation, the algorithm is inefficient as it renders every frame. We would strongly recommend drawing the operations on a piece of paper and trying to recognize a pattern.
Avoid byte-by-byte read and store. We have seen students using three load and store instructions for each pixel. This is very inefficient. There exists highly optimized code in the standard C library.
Avoid duplicated work. We have seen students allocating a fixed amount of memory for every operation and freeing it every time. Maybe there is a better way to reuse the resources.
Focus on loops. Make sure you don't do duplicate work in your loops.
If you want to try harder, consider the following aspects taught in class:
- Compiler optimizations (e.g. common expression, loop unrolling)
- Consider memory access patterns (especially cache locality)
- Use SIMD instructions (the testing machine supports avx2)
Q: What is considered cheating in this lab?
A: Please follow the the rules in the handout, e.g., do not use generated assembly, pragma, attributes in your code, make sure to call verifyFrame(), etc.
If we suspect cheating, you should be able to clearly explain why you wrote the piece of code and how it works. Obvious cheating examples include:
- Encoding results into the source code to avoid doing computation.
- Mimicking stdout that the autotester relies on.
- Caching previous execution attempts and avoiding doing actual work.
- Submitting other people's code or part of other people's code, etc.
When in doubt, ask the TAs. We check your submission against all current and previous submissions of the last 5 years.