TFA author. How does the word "dispatching" hint at the order of magnitude of anything? What orders of magnitude do depend on is your competition. Outdoing a CPU at operation X is easier than outdoing a GPU at X [assuming the GPU does X reasonably well] which is easier than outdoing a DSP at X [assuming the DSP does X reasonably well]. If your competition is reasonably optimized programmable accelerators, your opportunities to beat it start shrinking.
A group of 100 is 10 groups of 10. Does the autonomy of the group of 10 shrink as predicted by Paul Graham's "virtual person" argument? It might or it might not - and it's certainly not obvious that the constraints imposed on a 10-people company by their relationships with the external world are any better or worse, from any given angle, than the constraints imposed on a 10-people team by their relationships with the company employing the team.
Why do people contribute to projects like Linux or LLVM without getting paid for it? (Of course lots of them get paid to do this, but many are not.) It's not exactly easy calories for a caged lion, the way Graham describes a corporate job taken by recent college grads. Instead, people choose to work in these large groups because they want to make an impact. You can instead contribute to TinyCC or MenuetOS - smaller team, less impact. Are Linux or LLVM uninspiring? Were they only inspiring when they were too small for most of their current practical uses?
If productivity is concentrated in small companies - or companies of size X - why aren't companies of this size drive the other companies out of business? I think that market realities point in the direction of there being economies of scale and diseconomies of scale, without a single one-size-fits-all procedure for determining the optimal firm size for any particular endeavor.
If you work on/for a startup and that startup succeeds, it will more often than not have to grow. If you're unlike Paul Graham who sold his startup and then invested in countless others and made lots of money but did not keep working on the thing he'd built - meaning, if you're what he likes to call maker as opposed to primarily a money-maker - you will want to keep working on the thing you built. And this desire to keep working on that thing is what will prompt you to adapt your views on group size and how people thrive and lions and sugary food. And when you'll see what a hundred people can make out of what was started by ten, it will be very rewarding.
If a collar sits comfortably on a cat's neck, the cat will remove the collar. If a collar sits very tightly on a cat's neck, it's somewhat uncomfortable.
What if you're not home? It is for such occasions that cat flaps were invented. However, today's cat flaps either open for any cat, or they're RFID-based, and for that to work, you implant a chip into your cat, which I find utterly barbaric.
Now what could be a great improvement is a cat flap identifying your cat(s) and letting them in based on computer vision, instead of relying on implants. I'd pay good money for it, provided that it worked in all weather conditions and all cat conditions (a wet and dirty cat needs to get in even more than a dry and clean one but I expect false negatives in these scenarios.)
They don't show a comparison to bfloat16 PEs/FMA. IEEE half precision uses a larger mantissa than bfloat16, and the cost of multiplication is proportionate to the square of the mantissa size. I'd expect much lower gains relatively to bfloat16
It's certainly the case that neural nets work flawlessly because they're like the brain - ask any journalist. Without doubt, an image of the brain enhances NN performance
(TFA author) If it's a really important patent for an individual inventor as opposed to another one to add to the company's portfolio mainly to grow its size, then of course you want to do prior art search. I wasn't talking about the individual inventor's situation as I'm not familiar with it; perhaps you could elaborate on your reasons why your feelings are mixed after the process. I was talking about the situation of a typical company's employee. And yes, it's an "easy legal defense" for a product company to forego prior art search, but it's not an urban legend, it's real legal advice I heard from real lawyers.
The same applies to the lawyer's experience. If you're an individual inventor, you're gonna look for the lawyer with the best experience and the law firm with the best price (and IMO you're right in that the $1000/hour lawyers aren't necessarily the best for you.) If you work for a company, someone will find a lawyer to deal with your stuff and the lawyer will behave very confidently, in a "business as usual" kind of manner, when you explain them the basics and they keep not getting it, and you might naturally assume that's how things are supposed to work, when instead what you should do is push back against whoever set you up with this lawyer and insist on getting one with relevant experience.
Not sure why this is being downvoted. I admit that I find it hard to see how to control the exfiltration of data once it's been figured out by a badly sandboxed program. But the idea that systematically addressing side channel attacks in a sandbox is really hard seems very valid. I mean, the exploit described in TFA is quite the argument in favor of this point.
At my end, I wonder where the author ever saw deterministic computer systems. In my experience, you have to work really, really hard to get even a system computing outputs from inputs without processing any external events in-between to produce deterministic results, with things like floating point hardware and software and parallelism APIs, not to mention your own bugs, working overtime against you - to say nothing of faulty DRAMs and other such delightful phenomena.
A company leaving a large market will be outcompeted by a company which doesn't; for companies, ignoring profits kills them. If it's anyone's job to respond to China's government, it's other governments', as they can take losses more easily but still not easily enough to get by without coordinated action (easier for governments than companies since there are fewer governments and new states don't form as quickly as new companies.)
You mean if everyone teams up and makes their case politically, we'll all make far more, in real terms? So teaming up increases overall productivity? (Not impossible but would need more evidence than teaming up increasing bargaining power, though of course the latter needs evidence, too as a junior unionized worker doesn't have bargaining power against senior workers whom union arrangements incidentally tend to benefit.)
I'd think one is more qualified to address local challenges than global ones. Certainly all those people made their money focusing on the US market, not only because it's big and governed by relatively uniform regulations but because they understand it better than any other. For the same reasons, it's IMO far easier to be effective as a philanthropist closer to home. (This is not to say there aren't exceptions to this, just that there's a certain tendency for it to be true. Of course there's the somewhat-Rawlsian argument that you should focus on those worst off first; without addressing this argument in itself, I think you should also focus on those whom you can make better off most effectively and who in turn will likely do the most philanthropic work once their own situation improves, and at least for a US billionaire, US citizens sound like a great target demographic on both counts.)
Most useful C++ code is either not templates or it's templates which can be instantiated a finite number of times and then used like non-templated code. Most "header-only"/header-heavy C++ libraries which present the problem you mention solve problems like C++'s smart for loop working like "for x in xs" does in Python but not working like "for x,y in zip(xs,ys)" does or like "for i,x for enumerate(xs)" does etc.; you don't really need these outside C++ (whether you need them inside C++ is another question but it's irrelevant here.)
"I don't believe it's my position to enforce the amount of whitespace another developer has to use in their editor."
I suspect this might not be my most popular comment, but I honestly think that this is why tab users might actually make less than space users on average. On average, it's more productive to enforce things than leave everything configurable, thus different everywhere, thus harder to make sense of and debug. I knew brilliant people who don't want to "enforce" and decide and dim people who happily enforced and decided and it's always amazing how badly the former do career-wise relatively to their talent and effort, and how well the latter do relatively to theirs.
(Of course there might be another explanation for the data and I don't claim that my just so story is in any way scientific; though I think it should pass as a scientific theory in the social sciences.)
I always thought the opposite - x86 is perhaps more complicated (though ARM is the most complicated architecture calling itself "RISC" by far, especially the 32b ISA), but x86's emphasis on backward compatibility not only for user code, but for OS/privileged code (where ARM can change completely between revisions) pushes it to have less variability between implementations. In particular I'm almost sure that the memory ops ordering on x86 is more strictly defined with less room for differences between implementations/different execution scenarios given the same instruction stream than ARM. (This however is from hearsay as I never wrote production code for the x86 which depended on this stuff.)
rr helps with indeterminism. Memory sanitizers help only a little with that, and, sadly, any thread sanitizer working with POSIX-like threads also helps only a little with that. Reproducing the problem (somewhat differently every time) is one thing, reproducing it in exactly the same way every time and looking at state for as long as you want to is another ballgame entirely. And a 1.2x slowdown is not a ton. 2x is not a ton.
I've developed automated debugging tools, I debugged hundreds and hundreds of rare, irreproducible bugs or just bugs that are hard to figure out, I found things like memory ordering bugs in others' concurrent code just by eyeballing it because the bug was too rare to wait for it to reproduce, I debugged concurrent code on multicore chips without memory coherence, on faulty hardware, etc. You're entitled to your own opinion about what "the hard part" is, but I'm likewise entitled to mine, and I think rr is awesome and I disagree with you on every point.
Wow, only learned about rr today - an amazing project! Google for instance reported a sizable number of "flaky tests" which tend to pass but sometimes fail. Always running tests under rr would take care of that (since each failure would be reproducible.)
This is a huge deal. While I prefer the Cilk approach (automated debugging pinpointing places which can theoretically execute non-deterministically), it's not always applicable and isn't always or even often applied where applicable. This is definitely the next best thing, and in absolute terms, it's pretty damn good.
Couldn't it be both? That is, those are the people who can take risks because they are the only people who can put up with that lifestyle? (Not sure if it's true or more precisely to what extent it's true, in fact I'm pretty sure some startups did well without "that lifestyle", for instance a guy from LinkedIn wrote somewhere how they worked a standard work week; I'm just not seeing the contradiction implied by your "when actually...")
Sure, I just think my (not that well thought-out, but still) suggestion mitigates bugs in existing source code with fresh compiler support better than this thing does. A compiler/runtime using new instructions to make instruction addresses hard to clobber could instead use instructions keeping on-stack array sizes in the array pointer and maintaining it through pointer arithmetic. A compiler/runtime know when an array size is too large to fit into 23 bits, certainly on-stack arrays are never that big so your sister comment's problem about "4G" is not that big of a problem, just don't do this with large arrays.
It'd require somewhat more ISA & compiler changes but it'd solve more problems that just the one problem they solve, and I think the security of this would be easier to demonstrate, too.
Source: my day job