Viewing profile — no-bugs

This is Chapter 4 of the book; Latency vs throughput is discussed in Chapter 1.

> I recommend you stick a bone through your beard, pronounce yourself a performance guru, and make bank. Have fun. :-) :-) I LOVE when my opponent has to resort to personal insults…

> made millions of dollars of revenue... I'm not 100% sure you are well situated to lecture me about the 'real world' because you wrote an academic paper. So, we're going to discus…

> Honestly, it's a lot more complicated than that, and the article itself presents a pretty complicated (and flawed) model. There's no substituting for benchmarks. Of course, all t…

> may be a handful of microoperations merged in with a stream of other instructions. It may indeed in theory, but most of the time in real-world it won't. And BTW - let's not forge…

> My own benchmarks show costs that are nowhere near the ones cited. This is heavily dependent on the benchmark. In the OP, there is a ref to an academic research showing these num…

> The cost of virtual cals is usually due to missed optimizations and the possibility of misprediction. Yep (plus one L1 read to get that VMT pointer). And the OP is pretty much co…

However, the address of this C call is calculated, which means that branch prediction (and the cost of potential misprediction) is involved. So additional cost we're talking about,…

To be clear: I was NOT speaking of the first one :-). As for the second one: > the architect is the guy that can sketch that reporting engine that will be nurtured and improved by …

> by creating a God-like super-architect. Interesting point of view, never thought along these lines. On the other hand, thinking a bit about it - I don't feel that this approach r…

> You can code and knowledge share also. The problem with it is that there are only 24 hours in a day.

> how do you ensure that there are viable career paths for senior people who prefer to focus on code over "knowledge-sharing" kind of activities? From what I've seen, those Senior …

Added it, THANKS!

THANKS! I've added it (not 100% sure how it would work in practice, but certainly looks interesting).

Statistically - yep. See http://ithare.com/facelift-for-no-bugs/ - only 10 out of 160 said that they don't like the cartoons. BTW, there is a "very beta" way to turn them off - use…

> make a more efficient queue by using one-buffer-and-lock-per-thread. How the reader would block on such a distributed queue when it's empty (without creating one single mutex, wh…

> If this happens to you, you're doing it wrong. Except for some corner cases - you're right, probably I should add a note about it...

From what I've seen (YMMV), chances of it happening are MUCH smaller than chances of getting context switch under the lock (with lots of threads running into this lock and having t…

> Additionally, when you unlock a mutex before signalling the condition, another thread may be scheduled in between that may invalidate the condition that was signalled. This may i…

> Aren't most mutex/condition variable implementations optimized to avoid this case by deferring the condition signal to the mutex unlock? Yes, _some_ but not _all_ implementations…

Since IPv6 it is mandatory, but it still sucks :-(

BTW, when I've wrote about those "undetected network errors", I've meant those-network-errors-which-arise-in-UNENCRYPTED-packets (as 16-bit UDP checksum is certainly not enough for…

> Sorry to nitpick but UDP seems like the wrong protocol for authentication. While authentication over UDP is indeed a bit more difficult if implementing it yourself, fortunately t…

You're right, I forgot about it. But is there a ready-to-use library doing it?

Last thing I've heard was that specifically CurveCP was separated from libsodium into libchlorium, and it is not maintained now.