Simha Sethumadhavan

May 2020

Simha didn’t really know what he was doing, but he certainly tried. He was not a particularly good teacher, and I was lucky that I’d seen much of the first half of the course in Intro to EE; many of my CS friends were totally lost from the get go. We were all pretty confused during the second half as well, which covered computer architecture and assembly language. To his credit, Simha sent out regular surveys for feedback, and did seem to care. However, this does not excuse the fact that the problem sets were totally unlike what we had learned in class (as in going to class wouldn’t even prepare you to answer them, you’d need to read the textbook). Luckily, they were ungraded, and most people I know wouldn’t do them. The logistics of this class were the worst I’ve ever seen, and worse than anything I could possibly conceive of myself. Attendance factored into your grade, but since it was a 300 person class, Simha made us hold up signs with our name and UNI on them and then photographed the entire room (309), having the TAs search through the photo to mark us present. There were weekly “study groups (recitations) that were longer than class itself and factored into your attendance grade. These were really awkward, since everyone would sit there and not pay any attention to the poor TA. For the midterm, which was after the semester had been moved to remote instruction, Simha had us film ourselves, record our screen, and submit both for full credit. Yikes! I know he’s a security expert, but that is the dumbest thing I’ve ever heard, plus students were allowed to use the bathroom. Simha is a smart dude. He clearly knows the material well... he must have had a good professor when he took the class as an undergrad.

Jul 2018

The lectures were informative but they sometimes contained too much information that simply could not be digested in a 90 minute lecture (for example the lectures on DRAMs, out of order processing were discussed in great detail but required knowledge and hands-on experience, like VLSI, that was far beyond the scope of the class). There was too much breath and not enough depth in the class. For example, pipelining was discussed in class but there were no real, hands-on, "get your hands dirty" coding, simulation or hardware exercises to implement the idea. This can lead to confusion because as the semester goes by, the student sees more and more jargon/words without having had properly assimilated the information. But perhaps this is just representative of many classes at Columbia due to the lack of time and weariness students feel as the semester goes by. Some of the homework questions were based on optimizing code or running simulations of hardware, which is alright. But no circuit simulations. So more of a CS class than an EE class. Midterm was take-home and you had to skype the professor to discuss ideas. No practice final. So only lecture notes to go back on. Pretty difficult final because a lot of the material wasn't properly integrated into the homeworks/paper reading and the huge breath of the lectures did not properly prepare for the depth of the final. This class requires a lot more studying than it seems!

May 2016

I would not recommend this professor or course. A brief summary of two takeaways: 1. The course is artificially difficult exacting rote memorization of content delivered verbally rather than quantitative skills or abstract thought. 2. Timely feedback was not provided, grading seemed arbitrary and contradicted the syllabus. Sethumadhavan is knowledgable and encourages discussion during class. He waits for students to think through the examples he gives, entertains follow up questions and does not rush through the material. The midterm was challenging and a good opportunity to apply cache optimization techniques to a benchmark of scientific software. Sethumadhavan verbally delivered the majority of the content for the course. During this time he drew hundreds of rectangles on the blackboard to illustrate the interaction of different computer hardware components. This often seemed frivolous and distracting. Lectures were sometimes obfuscated by sloppy or incomplete handwriting. Slides might help to organize and deliver important concepts clearly and concisely. Grading seemed arbitrary and feedback was delivered late, if at all. No comments were provided on the implementation section of the midterm and the grade was returned the day before the final. After the course finished in May, the homework was decreased by 10% of the total grade and the midterm was increased by 10% of the total grade contradicting what was stated on the syllabus and on Canvas throughout the semester. CS is a broad field. Some courses may be challenging due to inherently abstract or mathematical content. This is not the case with computer architecture. If you study computer systems or are an aspiring computer architect you may enjoy certain aspects of the class; others may feel that the difficulty is contrived and the course lacks substance.

May 2016

This is one of those classes that every systems programmer should take, even if they will never design a chip in their life. You will lean so much about what actually goes on in a modern CPU -- much of which is not very well documented by online resources. It's essential for anyone who wants to write fast code -- for example, if you plan to work on operating systems, libraries, or high-frequency trading. I learned a lot from the lectures, despite being scheduled Thursday 7 - 9:30 PM when everyone is exhausted. Prof. Sethumadhavan was a great lecturer for the first half of the semester, but then he stopped making jokes (probably because he was tired like the rest of us - but jokes help us stay awake). There are definitely some lectures that were extremely dry even though they could've been interesting. Also, his explanations are unclear (self-contradictory) sometimes on complex things, like how to access a DIMM. The most helpful part of the course was taking with Prof. Sethumadhavan during halftime and at the end of class. He is really great at explaining stuff in small groups and genuinely takes pleasure in hearing interesting questions from students. Wish I had attended office hours more. The problems from the book truly horrifying - they are filled with ambiguities and errors - but my understanding is that there are not that many textbooks about computer architecture. Maybe there are some non-textbooks that we could integrate into the course. However, I really enjoyed the group homeworks where we had to argue about how to interpret computer architecture papers and write programs to demonstrate concepts from class. The midterm was in the same vein - come up with some optimizations and then implement them - so I also enjoyed it a lot. Sometimes the assignments were poorly worded or had bugs. For example, the hw3 skeleton code did not properly check whether the optimization changed the program's output, despite several corrections by the TAs over two weeks. This did not affect our group because we figured it out, but had we not been so careful, we could've wasted a lot of time and had nothing to show for it. I understand that TAs are busy, but correctness is also important.

May 2014

Great lectures, Prof S is explains things well and knows his stuff. Would be even better if he made slides for all lectures and posted them. Very poor logistics and not enough TAs - grades took forever to get back, room overcrowded in 1st half of semester, not much help on Piazza, etc. Early HWs did not really relate to the test much and were long, later HWs were more reasonable. Far too much reading was assigned, but you didn't really need to do it all anyway. Doesn't let non CVN students view the lecture videos online which is unfortunate. Hopefully he'll keep teaching the class, and improve on the TA and logistics in future semesters because the core of the class - his lecture ability - is solid.

Apr 2014

Spring 2014 is the first time Simha has taught Computer Architecture. He didn't have a lot of slides, and used the blackboard for a majority of the course. Nevertheless, he is a good teacher: he takes times to explain concepts clearly, and actively takes questions. However, he doesn't employ nearly enough TAs, due to which assignments and exams are returned horribly late. Moreover, half the assignment just lists textbook exercises -- and the exercises in the Hennessy & Patterson are really ambiguous and poorly designed. The other half is a group portion that involves either reading papers or running simulations, which is not bad. The exams are very sensible and test exactly what Simha taught in class. Overall, I enjoyed the course and learnt quite a lot.

Jan 2010

Simha is the worse professor I've had at Columbia. He gaves way too much work; the work from his class was more than the work from all my other courses combined. He doesn't seem to understand what a reasonable amount of work is. His lectures are extremely boring and hard to follow. The assignments and tests are poorly written and are ambiguous making the already difficult work even harder. As a person he's kind of a nice guy. However as a professor he seems to think that students have no other commitments beyond his class. Overall, avoid this professor at all costs.

Apr 2008

Professor Sethumadhavan genuinely has a passion for the subject and makes an effort to teach. However, his teaching method is not too effective; he comes in with powerpoint slides, but unless we've read the book thoroughly prior to the lecture, it's very difficult to keep up. Sometimes, he'll realize that he made a bad lecture, and he'll come to the next lecture being a lot more prepared. I have to give him an A for effort. He makes some joke in class, which weren't funny, but at least it shows that he tries to lighten up the mood. He also makes an effort to remember your name. This is his first time teaching in Columbia, so hopefully, by the time he teaches this class again, he'll be better prepared and teach a lot better. The textbook for the first half of the class (Brown and Vranesic, Fundamentals of Digital Logic with VHDL Design, McGraw Hill Publishers, Second Edition) was very poorly written (it refers to examples that require the reader to flip back ~10 pages), but the one for the second half (Patterson and Hennessy Computer Organization and Design: The Hardware/Software Interface, Elsevier, Third Edition) was much more well written.