Any systems/computer org class. http://www.amazon.com/Computer-Syste...7s+perspective is a great book (used it for the class I took on it). The hardware/software interface looks like it was a great class, but for this kind of stuff you really need practice in addition to the lectures and the problem sets/quizzes aren't available unfortunately.

There are four relevant classes here - Computer architecture, compilers, operating systems and computer networking. Solid undergraduate-level understanding of these topics is enough theory for most programmers to reach the top of their specialty. Because practice diverges significantly from theory, it's not even necessarily helpful to go beyond undergraduate level. Of those four, the compilers course is one where practice tracks theory best - in the other fields, most of the academic work beyond tends to have little applicability. This isn't because academics are too out-of-touch or practitioners too dumb, it's just that the other three areas are winner-take-all fields dominated by decades-long incumbents with little room for new ideas.

The chance is, nothing can be done about this though - this is true of most L1/L2 caching issues - your working set is bigger than the cache, what can you do? It's extremely rare to run into a situation where all of the following conditions are met: 1) L1 and L2 cache misses are your bottleneck, 2) you're working at a level of abstraction where caching behavior can be controlled, and 3) there's an alternate algorithm that significantly improves memory access locality.

You're probably right that this is a rare case, but the whole purpose of the huge lookup table is to improve performance. It actually performs very well if you evaluate the hands in order. But if you need to evaluate random hands, it's better to use smaller tables that fit in cache and do more computation. It's a trade-off between pre-computing and reading from memory or computing on the fly. It's useful to be aware of the cliffs when you are making those trade-offs.

Do you think that it's worth it for most programmers to master those topics at an undergrad level, regardless of what they're doing? I.e. is it worth it even for web devs, Android devs, computer vision devs, etc to know that stuff?

I don't think it's worth mastering those topics for a web dev but there is huge value in learning stuff slightly below the level you program at. Being comfortable with managing your own memory, knowing how the stack/heap work and knowing just enough C to be dangerous seems beneficial for anyone using python/ruby/js/etc..

Being aware of common timings like that gist is also quite useful.

The thing is you need to be at ludacrious scale before you get past the low hanging fruit which is just basic knowledge of DB tuning and writing semi-efficient code in your language of choice.

In web dev a lot of performance related issues are a combination of poor DB queries, not caching enough and having a crappy architecture. All of which can be solved with a little bit of self research.

A $40ish/month VPS with an SSD can handle a surprising amount of traffic if you cache aggressively.

I think it also depends on what you're working on (as a web dev). For me, I'm building predominantly greenfield apps which aren't likely to go mega viral. My main attempt is building stuff that works. I do my best to architect the apps as well as possible (in terms of my knowledge of DB designs), avoid egregious queries, or terribly slow code in general. And with things like heroku, I'm sure my apps would scale well enough for a while.

But everything I've worked on so far has been against a pretty nasty time crunch. The first site I built, the guys took the MVP I built (by myself in like two months) and went on to raise 1.5 mil very quickly. I'm sure they're fixing some of the stuff I ignored/was ignorant of as they scale up and hire some devs that work on bigger projects than I'm used to.

Frameworks like rails take care of so much of that stuff for you, that I honestly think it's probably actually detrimental to think about a lot of that as you go (in that you're risking overengineering a simple problem, and wasting a lot of time in the process). Things like structuring applications well, writing readable code, writing tests, and making sure your app is secure all seem like more important things to worry about. The real world benefit of saving a few ms of server time on a page load seem quite negligible to me until you have a huge user base.

I'm not arguing don't keep learning, but just that those timing things should probably be very low on a priority list for a web dev.

On another note, firefox's javascript engine just seems way faster than chrome's these days. What do you guys use on mac? I use chrome because I like the interface/developer tools better, but everytime I use firefox, it's just way faster. I'm torn.

Probably not. At the same time, what was the equivalent of web dev and android dev in the early 90's? Fundamental knowledge is not as immediately useful, but is more likely to last. It also depends on your ambitions and career plan. If you want to go very far on your technical ability, it helps to understand the fundamentals as well as you can. If you are not as ambitious or can leverage other skills to move up, such as strong domain knowledge, managerial ability or sales acumen, it may not be as important.

From a more cynical perspective, a firm understanding of these topics is going to come handy for tech interviews on both sides of the table and in a developer-centric company like Facebook, Google or Microsoft, lack of fundamental knowledge is a social marker that can hinder your career progress.

I use Chrome for the interface as well, but sometimes I wonder if that's more just because I'm used to it.

Are people using jstl on new projects nowadays? Has jsf actually started being used? I tried thymeleaf for a bit but just found it awkward and annoying. I definitely have more comfort with jsp but everyone kind of acts like it's dead it seems

Are you sure you're talking about Javascript engine, not rendering? On Windows 8, it appears to me that Chrome > IE11 in Javascript performance but IE11 > Chrome in terms of on-screen rendering. It's quite unlikely that in 2014, anyone is that far ahead of the others for most sites that are not using experimental features.

You're probably right. I just assumed the two would be highly correlated.

I'm writing an app right now that renders some excel like tables with a pretty huge amount of data (huge dummy data json file, and no pagination yet). When I redraw the table, chrome chokes a bit at times. Firefox renders it with absolutely no problem (on my 2012 retina mbp).

IE11 is pretty screaming fast at rendering.

That's my point. You should worry about them more often than many people do.
I know I have written naive loops that have created arrays/lists with 5k elements and that's already too big. And I'd argue that you should write for way less L1 cache so 3k is probably too much already.

Granted you don't need to know anything about L1 cache to use iterators instead of lists but I think it's pretty good to at least know the reasoning behind it.

Agreed. There's probably some money to be made writing and marketing one of these ZOMG I sold n*n*n of this silver bullet ebooks. "CS basics every programmer should know" and market to the self taught (or people who are going to teach themselves) programmers that are becoming more common these days.
$_$

I'm sure I've occasionally gotten out of the wrong exit off the train station, forcing me to cross the street unnecessarily and increasing the chance of a premature death but that does not mean I need to have all NYC subway train station exits memorized. L1 cache becoming even a thought that comes across your mind is a mistake except when you're explicitly optimizing an innermost loop that needs to run millions of times fast. Almost no one works on that kind of stuff. Your working memory, just like L1 cache, is quite limited and the idea of L1 cache is displacing a more deserving occupant.

In general, L1 cache misses are some of the most unlikely optimization corner cases for modern programmers and in most circumstances, not much can be done about this other than using data structures with better memory locality.

For example,

http://x264dev.multimedia.cx/archives/149
http://x264dev.multimedia.cx/archives/201

We have a perfect situation - someone who's clearly skilled with low-level stuff, working in an area where getting the maximum CPU performance is essential, identified that L1 cache misses are indeed the bottleneck. And he finds nothing that can be done about it.

Using a language that has iterators is a sign that L1 cache issues don't matter to you. If you're using anything other than assembly or C (or C++'s mostly C-ish subset), you are highly unlikely to need the extra performance and are unlikely to have the tools to address the problems uncovered.

This is even better:

http://c2.com/cgi/wiki?RulesOfOptimization

I'm trying to upload multiple videos to youtube, all of which are roughly 2gigs. Vids ~45 min long. This is post-encoding (in raw format, each video is ~100gigs). My home internet's upload speed is **** b/c i never need it, but right now (to get them onto youtube) i kinda need decent upload speed because it says its going to take about 500 min to upload 1 video and it ties up my entire internet during that time which is not okay. Anything I can do?

I was thinking maybe there is a site where u can upload a file and let them upload it to youtube for you xD

Unless I'm missing something, wouldn't you run into the exact same problem uploading to that site?

No I think it might be that youtube has a cap on how much you can upload per second?

candybar I think your point is generally valid (premature optimization etc.) but my main point was that of all the low level things that's the most important one imo (mostly because I've run into it). I couldn't say for sure but I think it's not too uncommon to find "dumb loops" etc. in large codebases.
It's usually the first thing I look for when code seems sloooooow

[I've also run into page alignment issues but not in a higher level language]

I have to say I don't think I've ever had to optimize around problems like this. For me it's almost always:

- a slow database query
- a 'slow' operation (db, network, fs, ...) being called in a poor way, like looping around a db call that should be done in one call.
- generally poor algorithm implementation.

No, it's much closer to the least important - it costs little and in most cases, there's no workaround.

Do you remember what your L1 problem and workaround looked like? xrange/range stuff is kind of tangentially related, but it fundamentally has nothing to do with L1.

This - almost all unnecessary slowness in application code these days has to do with unnecessarily making or waiting for system/foreign API, or completely broken application/algorithm/data-structure use/design.

Looking at this,

https://gist.github.com/2843375

L1 cache misses cost 6.5 ns. Even 10 million of those cost 0.065 seconds, which has close to no impact on responsiveness. How often do you have to do anything 10 million times in your own code to show the user something? How often does this involve using the same data over and over again? You're making worse mistakes elsewhere.

Edit: and to properly optimize, you're going to have to know all this crap for your particular processor:

http://infocenter.arm.com/help/index.../CHDEFDHG.html

I think it's intuitive to even beginning programmers that it's more efficient to generate the items one by one as needed vs allocating them all in memory at once. No cache explanation needed.

That said, at least for me it was eye-opening when I first learned that a main memory reference can be ~100X slower than L1 cache. That seems like something most programmers would want to know, even if it doesn't come up often. According to wikipedia, Sandy Bridge L1 and L2 cache access take 3 and 8 clocks respectively, so much less of penalty for a L1 miss that hits L2.

Agreed. And range() returning a list in Python 2.x is more of a bug in the language, in Python 3 range(), dict.keys(), dict.items() all return generators.

I'd rather not talk about details but it involved real time tracking of a lot of items that moved a lot (not NSA, I swear :P)...and the codebase was initially developed for not that many items that hardly moved at all.

I'm kind of with you that you pretty much never need it but it seems like a concepts that just makes sense to know. At least it feels more important that other low level stuff i.e. intricates of saving an opcode or whatever comes to mind.
If my background was different I might have a completely different view, too for example a lot of low level stuff is fairly relevant for security critical things and I rarely worked in settings where networking stuff mattered at all.

But for argument's sale, list a couple of low level items that you think are important (maybe we kind of disagree on low levelness to boot :P). I'm also faaaaaaar from an expert on these issues so I'll gladly yield to your experience.

Those are all waaay more important (especially fixing the last usually means you don't even have to think about caches) but I'd consider none of them low level

Slow FS was always the #1 for me (well I just handed off DB stuff :P)