71–80 of 101 posts
It has all been from more experienced coworkers, and I would much appreciate any resources anybody could point me to (free or paid) so that I could round out my knowledge
Is this title and content supposed to be ironic? I quickly perused the article and I think this link should be renamed "What 99.9% of programmers don't need to know about memory." I've managed to go from Associate to Principal without knowing 99% of what's covered in this document, and I'm struggling to understand why the average Java, C#, Python, Rust, programmer would need to know about transistor configurations or…
I would argue that the overclocker needs to know more about these details than most programmers, yes. (Overclockers actually tweak these values to maximize the performance of their computer). But any high-performance programmer needs to understand the RAS / CAS / PRE cycle, if only to understand WHY the "streaming" of data is efficient, while random-access is very inefficient. If you are accessing RAM randomly, you b…
Is this title and content supposed to be ironic? I quickly perused the article and I think this link should be renamed "What 99.9% of programmers don't need to know about memory." I've managed to go from Associate to Principal without knowing 99% of what's covered in this document, and I'm struggling to understand why the average Java, C#, Python, Rust, programmer would need to know about transistor configurations or…
Every programmers should know something about memory, because software are becoming bloat [1] [2] because of a new generation of programmers who doesn't optimize their code. So, of course, you had a wonderful career, but it doesn't prove that you write efficient code [1] http://www.rntz.net/post/against-software-development.html [2] http://tonsky.me/blog/disenchantment/
Most programmers are working for a business whose goal is to make money. Usually that involves adding more features or producing the product faster (as in development time). As far as optimal or efficient goes, all the company cares about is: "Is it fast enough so that people still buy/use the product?"
Premature optimization is wasteful, both a waste of time and money. Unless you're doing it for fun, trying to eke out 1ms on a website load at the cost of excessive dev time and risk of bugs, is just silly.
Don't forget, trying to make super optimal code often introduces bugs as you now have code that is more complex and/or uses more low level constructs. I've seen many deadlocks and race conditions due to engineers trying to optimize code unnecessarily.
I was so excited to dive into this, but ended up with the same Takeaway as most other commenters. Aside: As a data scientist, I’ve been surprised how much I’ve needed to learn about the finer points of optimizing GPU utilization for training. It has all been from more experienced coworkers, and I would much appreciate any resources anybody could point me to (free or paid) so that I could round out my knowledge
The profiler not only tells you how fast your code is, but also why your code is fast or slow... at least to the best ability of the hardware performance counters.
Is it RAM-bottlenecked? Is it Compute bound? Are your Warps highly utilized? Etc. etc. If you don't know what the profiler is saying, then study some more.
https://docs.nvidia.com/nsight-visual-studio-edition/Content...
Earlier quoted context omitted.
I would argue that the overclocker needs to know more about these details than most programmers, yes. (Overclockers actually tweak these values to maximize the performance of their computer). But any high-performance programmer needs to understand the RAS / CAS / PRE cycle, if only to understand WHY the "streaming" of data is efficient, while random-access is very inefficient. If you are accessing RAM randomly, you b…
You don’t need to know any of that to know that streaming access is more efficient than random access. You just need to know that caches cache localized blocks. Actually, you don’t even need to know that. You could even just be told that streaming access is faster than random access.
Earlier quoted context omitted.
I am all for knowing things just to know things...but why does a programmer need to know WHY the streaming of data is efficient?
Because fundamentally, the DRAM is a major component of the computer, just as CPU cores are a major component of the computer. Now, I'd personally explain things in a far more simple manner than what was described in the PDF. Here are the facts that programmers need to know: 1. DRAM stores data in very tiny capacitors. These tiny capacitors have two properties: they run out of electricity in just 64ms. And second, th…
Is this title and content supposed to be ironic? I quickly perused the article and I think this link should be renamed "What 99.9% of programmers don't need to know about memory." I've managed to go from Associate to Principal without knowing 99% of what's covered in this document, and I'm struggling to understand why the average Java, C#, Python, Rust, programmer would need to know about transistor configurations or…
Every programmers should know something about memory, because software are becoming bloat [1] [2] because of a new generation of programmers who doesn't optimize their code. So, of course, you had a wonderful career, but it doesn't prove that you write efficient code [1] http://www.rntz.net/post/against-software-development.html [2] http://tonsky.me/blog/disenchantment/
Reading a paragraph like this:
> "The CAS signal can be sent after tRCD (RAS-to-CAS Delay) clock cycles. The column address is then transmitted by making it available on the address bus and lowering the CAS line."
is certainly interesting but it offers no additional insight in to how to write an efficient program. Regardless of whether the row and column addresses are sent on the same bus or a different bus, the optimization strategies for programmers are exactly the same. The same goes for almost all of the information here.
Unless you're writing a kernel, 99% of this article is overkill. I mean that literally: it's over 100 pages long, and I think the important and relevant points for most programmers could be summarized in a page or two.
Earlier quoted context omitted.
The referenced work talks about floating point errors that both computer scientists and field engineers need to avoid. Many folks in both camps screw up on floating point code without such guidance. So, at least that part is potentially helpful. You just proved their point about how you'd reply, though.
Proved their point? Their point didn't make much sense. What actual engineers NEED to know about floating point numbers could be put on a single A4 page. It doesn't have to be 50 pages, where many of those pages are full of equations that 99% of engineers don't understand. My point is, because you seem to have trouble grasping this. Most real-world programmers, working at startups or bigger companies, making their WP…
Please don't insult people like that.
If someone doesn't follow your reasoning, take responsibility yourself and find another way to explain the point so others may understand it more easily.
Earlier quoted context omitted.
The referenced work talks about floating point errors that both computer scientists and field engineers need to avoid. Many folks in both camps screw up on floating point code without such guidance. So, at least that part is potentially helpful. You just proved their point about how you'd reply, though.
Proved their point? Their point didn't make much sense. What actual engineers NEED to know about floating point numbers could be put on a single A4 page. It doesn't have to be 50 pages, where many of those pages are full of equations that 99% of engineers don't understand. My point is, because you seem to have trouble grasping this. Most real-world programmers, working at startups or bigger companies, making their WP…
Earlier quoted context omitted.
memcpy != memmove , $#$@#@ https://sourceware.org/bugzilla/show_bug.cgi?id=12518
https://sourceware.org/bugzilla/show_bug.cgi?id=3266 https://sourceware.org/bugzilla/show_bug.cgi?id=12701 https://sourceware.org/bugzilla/show_bug.cgi?id=386 https://sourceware.org/bugzilla/show_bug.cgi?id=10134