_yosefk

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.

Source: my day job

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.

What's the difference between France (lost quickly in WWII), Britain (barely evaded invasion), and the US (not invaded, economy grew during the war)? Is it democracy, free markets, or accessibility to German tanks and war planes that is the likely reason for the difference?

8 out of 10 Germans losses were inflicted by the Soviet Army; the USSR didn't rank high on democracy or market freedom but it had no choice but fight Germany, whereas the US could afford to choose the extent of engagement and let the USSR (and Britain) bleed while inflicting losses on Germany. This is not to say that the US policy wasn't sensible for the US, just that WWII is not a clear testament to the latent strengths of democracies and free markets at waging war.

And on the point of democracy specifically, in "The Gathering Storm," Churchill nearly pins the breakout of WWII on the inherent difficulty of conducting sensible foreign policy under democracy (both in the case of the badly designed peace treaties at the end of WWI, and in the case of subsequent appeasement of Nazi Germany.)

I wouldn't want to live where they don't have democracy or a reasonably free market, but neither is a reliable device to either prevent or win a world war.

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.

Wrt "run with no cache": is a shared DRAM that much better than a shared cache? The DRAM state is affected by what previously accessed it, in fact DRAM effectively has an SRAM on-chip "cache" keeping the current active row per bank. ("Cache" in quotes because it's a bit crummy if you think of it as a cache - there's just one way, #lines is 4-8 and their size is measured in kilobytes - but technically it's a cache.)

Glad you liked it! It is unfortunately quite out of date as it does not address C++11/14/17; so I put it on github in the hope that people would take over it, as I personally no longer care enough to invest the time it takes (at most I might publish a blog post on this, working title: Modern C++ Feels Just Like Python, My Ass.)

No problem beating most humans already. Beating the best human? How much energy goes into creating a civilization that produces that human? Such humans are rare so you ought to count all the others as part of the cost of making the best human as you can't quite make them on demand (though Laslo Polgar might disagree).

I don't get the energy point. The machine has no health care costs and can play 24/7. Doesn't that count for something?

But your wish will come true. Go isn't a special snowflake. If you have an objective metric of success in a formal universe machines always win.

If advertising is a cancer on society, what is advertising? If someone blogs on their company's platform and this is submitted to HN, or there's a "we're hiring" post on HN, or someone replies to "who's hiring", is that an ad and therefore cancer on society? If I enrolled to an evening school which I heard about from a YouTube ad which clearly knew my interests (real story), is that cancer on society or, since I think it was valuable and did not directly contribute to urbanization and other issues, is this no longer an ad because if it were an ad it would have been cancer?

You do value some citizenships more than others though, right? Or would you trade yours for any other? If not, I don't think it makes you a "nationalist", but neither would opposition to free movement from places you don't want to live at into where you do.

It does not follow from not valuing some people more than others that free movement would benefit any of these people; IMO part of a "moral" position involves trying to guess the likely consequences of things in the real world. An argument that people from different cultures don't get along very well, particularly when there's a large and sudden change in the numbers of one of the groups, is not antithetical to your position of valuing people equally; the only point of disagreement is wrt likely outcomes.

Isn't taxing income making r>g?

A wealth tax isn't unimplementable because of political will but because a lot of assets are illiquid, hard to price, easy to hide, easy to move to another country (hence the call for a global tax, but what if a few countries defect?) or a combination.

As to approaches: "the left" if there is such a thing successfully campaigned for a full confiscation of property, a 100÷ wealth tax if you like, in huge chunks of the world - I don't see a weakness in persuasive ability there. Wasn't a great idea though. A smaller wealth tax is a better idea, but still not great. Baker who one can agree or disagree with has better policy ideas, or at least better thought-out and consistent ones IMO.

Dean Baker (warned of the housing bubble since 2002, "Bernie 2016") gave the best response to Piketty that I heard from a left-wing economist:

* Piketty's data is correct

* him collecting it was a harder feat than one might think

* attributing r>g to some unchangeable nature of capitalism is wrong because "capitalism is infinitely malleable" (every market is regulated somehow, things change a lot depending for instance on whether you do or don't have patents)

* Piketty's policy prescription (a global wealth tax) is unimplementable and harmful in the sense of getting all the attention instead of people focusing on his correct assessment that r>g and then on realistically implementable policies which could change this.

Got it, an interesting point and it follows that a use case can be engineered where a GC adds essentially zero overhead over an arena allocator.

But in the general case where some objects are short-lived and others aren't, surely manually splitting your allocations to malloc for long-lived ones and some sort of arena_alloc for short-lived ones ought to be faster than allocating them all in one place, then copying the ones which are still reachable out of the area reserved for short-lived objects?

(This is not to say a GC-based system will be slower "on average" because nobody knows what the "average" is. A realistic arena-based system can have objects most of which are short-lived but some do need to live longer and you only find out long after they're allocated; in that case, one has to manually reallocate those objects just like a GC would, and doing it, say, the C++ way is definitely more bug-prone than GC's bug-free handling of this, and one way to make it less bug-prone in C++ is to have deeper copies and avoid trying to minimize copying, and now you might easily be slower than a GC. I'm just saying that it's very easy to find a case when a system not getting any hints from the programmer wrt object lifecycles and instead discovering them fully automatically would be slower than a system which does get these hints. And of course a GC can provide ways to supply these hints, I'm just not aware of one which does - perhaps it's avoided on the theory that the GC algorithm might change and you don't want to make hints which operate in terms not portable between algorithms a part of your interface.)

Isn't it harder to deallocate the data if you actually check that it's unused, as a GC must, instead of just assuming it?