<div dir="ltr">On Tue, Sep 3, 2013 at 4:05 PM, leam hall <span dir="ltr"><<a href="mailto:leamhall@gmail.com" target="_blank">leamhall@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div>Hey all, reverse question. Coursera has a Computer Architecture class starting in a couple weeks.<br>
<br><a href="https://www.coursera.org/course/comparch" target="_blank">https://www.coursera.org/course/comparch</a><br>
<br></div>I like the *idea* of knowing that sort of stuff but I've never been in a job that would need it. Has anyone done so and can you tell me, on list or off, what the job was like? I'm certain I want to know more and do more, but don't want to spend time chasing the wrong dream. This course is one of several I could take, so I'm trying to pick one and go with it.</div>
</div></blockquote><div><br></div><div> I think that the stuff I know about how hardware is designed makes it easier for me to talk to the software developers who really understand how the hardware works.</div><div><br></div>
<div>For example, if I really understand the way the CPU cache is designed, the tradeoffs, etc., then it helps me remember how the caches really work, and then I can learn and retain the reason why you need a memory barrier in some circumstances, and then I can intelligently talk to someone about why it's safe or dangerous to do such-and-such in the implementation of a more scalable locking primitive without using a memory barrier.</div>
<div><br></div><div>Well, I guess to be fair it gets me halfway there. There's also the stuff that makes a memory barrier important, like compiler instruction reordering (not relevant to the arch class) and CPU-level instruction reordering (arch-class relevant). For the latter, understanding branch prediction, instruction pools, etc., is a good background!</div>
<div><br></div><div>If the levels of software you're planning to work with are way higher than the systems programming level, then I can't say how relevant you'll find the course. And it's really hard to learn if the material doesn't seem relevant.</div>
<div><br></div><div>By the way, I saw you mention assembly language, and I've recently refreshed what few skills I have in that area by re-learning NASM, this time for x86_64. I have two little things on github in a "low" repo you can see. I use Linux and Mac OS X for these toy examples.</div>
<div><br></div><div> <a href="https://github.com/ecashin/low">https://github.com/ecashin/low</a></div></div><div><br></div>-- <br> Ed Cashin <<a href="mailto:ecashin@noserose.net">ecashin@noserose.net</a>><br> <a href="http://noserose.net/e/">http://noserose.net/e/</a><br>
<a href="http://www.coraid.com/">http://www.coraid.com/</a>
</div></div>