How profilers lie: the cases of gprof and KCachegrind
We'll see how gprof and KCachegrind lie to us and why they do so, discuss the limits within which we can trust them nonetheless, and attempt to draw more general conclusions about profilers and profile visualization tools. (In case your programming vocabulary is different from mine – I use "lying" in its dispassionate meaning of "communicating falsehoods" and not to convey negative judgement; on t
C as an intermediate language
Here's a Forth program debugged in KDevelop – a graphical debugger without Forth support: Cool stuff, not? The syntax highlighting for Forth files – that's someone else's work that comes with the standard KDevelop installation. But the rest – being able to run Forth under KDevelop, place breakpoints, and look at program state – all that stuff is something we'll develop below. I'll show all the req
Error codes vs exceptions: critical code vs typical code
Error codes or exceptions – which is better? Here's my answer: They have the same worst case – a human error can lead to a complete disaster. Exceptions are far safer for most code. Error codes are far safer for well-reviewed, critical code. (As you can see from 2 and 3, I believe that most code is not critical and/or poorly reviewed; I think most people will agree on that one.) Worst case: disast
What "Worse is Better vs The Right Thing" is really about
I thought about this one for a couple of years, then wrote it up, and left it untouched for another couple of years. What prompted me to publish it now – at least the first, relatively finished part – is Steve Yegge's post, an analogy between the "liberals vs conservatives" debate in politics and some dichotomies in the professional worldviews of software developers. The core of his analogy is ris
"It's done in hardware so it's cheap"
It isn't. This is one of these things that look very obvious to me, to the point where it seems not worth discussing. However, I've heard the idea that "hardware magically makes things cheap" from several PhDs over the years. So apparently, if you aren't into hardware, it's not obvious at all. So why doesn't "hardware support" automatically translate to "low cost"/"efficiency"? The short answer is
I can't believe I'm praising Tcl
So the other day I both defined Tcl procedures all by myself and used them interactively, and I liked it, to the point where it felt like some kind of local optimum. This entry is an attempt to cope with the trauma of liking Tcl, by means of rationalizing it. I'll first tell the story of my fascinating adventures, and then I'll do the rationalizing (to skip the oh-so-personal first part, go straig
SIMD \< SIMT \< SMT: parallelism in NVIDIA GPUs
Programmable NVIDIA GPUs are very inspiring to hardware geeks, proving that processors with an original, incompatible programming model can become widely used. NVIDIA call their parallel programming model SIMT - "Single Instruction, Multiple Threads". Two other different, but related parallel programming models are SIMD - "Single Instruction, Multiple Data", and SMT - "Simultaneous Multithreading"
Work on unimportant problems
"Work on important problems": ~40900 results. "Work on unimportant problems": ~18 results. – Google (at the time of writing), tempting the contrarian in me It seems obvious that some problems are important to solve and some aren't, as in, curing cancer is more important than delivering social gaming. Often, people lament the abundance of tech firms working on ultimately unimportant stuff, and advi
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
"Value", the irksome euphemism
Do you really want to be making this much money when you're 50?