_yosefk

Grandparent is writing numerical code. I doubt that Go which has neither operator overloading nor built-in types such as vector/matrix will work here.

I think the main concern is that they might go extinct.

(Regarding the cockroach - don't Americans have the right to shoot human tresspassers? The crab on the other hand is plucked out of water which is its own home. This is not to say I'm against the practice - I'm not, unless the crab might go extinct.)

I'm in it for the money and haven't failed hard enough to prompt much supervision in a while. Intrinsic/extrinsic has nothing to do with it (I struggle with some things I'm intrinsically motivated to do more than programming.) Certainly "person X doing Y" requires different amount of supervision depending on X and Y but I think we know little about exactly how and why it varies.

One source of variability: some care about impact on coworkers, some don't. Guess who will upset you more. Intrinsic/extrinsic is orthogonal to this.

Those full color images are way worse than the sketches in TFA which look like a person could have drawn them.

What are some practical things done with GA's chips? (My own belief is that almost nothing can be done with them but I'm always glad to be surprised, certainly with something like this where the chip itself is a masterpiece of circuit design shunning every convention of the art.)

Leaving it consumers to worry about fraud is not how you create a functioning market economy. The real equilibrium in places where fraud isn't punished is you rely on the market as little as you can and everyone is poorer as a result. Fraud is illegal for good reasons.

Where does it say that "thou shalt not kill" does not apply to gentiles, in any Jewish religious text from any time? And by that of course I mean "does not apply to gentiles, period, kill them as you'd kill animals, no biggie" as opposed to laws about waging war etc. - which is the only non-weasely interpretation of "does not apply to gentiles"?

It wasn't infinitely bad for James Clapper to have lied under oath about NSA's data collection. It wasn't infinitely bad for the US to have been caught spying on Merkel. Etc. etc.

Everybody spies on everybody, everybody accuses everybody, everybody lies about both, gets caught and mostly doesn't care. The allegations prove just as much as the denials - nothing. Eventually one side will be caught lying, and nothing will happen to them.

Of course you can prove me wrong or more precisely convince me I'm wrong (proofs are hard with these things.) Just show me enough monarchies or dictatorships fending off immigrants from established democracies instead of shooting would-be emigrants in their backs.

It also so happens that I'm dumb enough to have wasted time listening to arguments from neoreactionaries living in democracies and thinking about them. But mainly I think the test should be empirical.

I only said he had praise for Castro, a dictator whose soldiers shot people trying to escape his rule in thd back and drowned their boats. I didn't say he was against democracy, only that he said very nice things about a dictatorship that he sure isn't dumb enough to live under.

Doesn't unrestricted immigration also eliminate the choice of some (those whose government enacts different policies with the new voters)?

I don't think "choice" is how you decide these arguments. Either your choice to make noise limits my choice to sleep or vice versa. There is not always a way to limit the choice of none.

"Defenders of democracies" live in democracies. Defenders of dictatorships and monarchies, from Jeremy Corbyn (who had kind words for Castro) to neoreactionaries, also live in democracies, presumably because they're not actually stupid enough to believe what they say.

Democracy is a lesser evil, which many people born into it fail to appreciate because their imagination does not render the greater evils realistically.

And in this story he claims that abacus use is mechanical and rids you of having to "know" numbers or approximate methods or understanding anything about the computation and why answers come out as they do. You're just executing steps and the more complex the computation, the more steps you do with no understanding whatsoever. So the opposite thesis from TFA.

While it's hard to argue that it runs in the family to some extent in this case, David Friedman is an econ thinker in his own right and certainly goes way further into what most would call extreme libertarian/"uber-rational econ" territory than Milton Friedman ever did. In fact, I'd say that "The Machinery of Freedom" ought to entitle David Friedman to the simpler introduction "...because the author is David Friedman."

It's kinda funny, but I kinda don't want to make fun of it, so I'm left speechless. Maybe others too? Hence no comments on the content in a hour?

I do think that the Turing test is still the greatest test for strong AI, machines are still very far from passing it, and I feel that understanding human emotion should be a part of the general strategy of "understanding human things" on a level sufficient to pass a very long Turing test session:

* From a technology standpoint it's not clear that what we'd call human emotion requires a different approach than other "human things."

* From an application standpoint, a machine much dumber than an adult (as in totally can't pass the Turing test) but with developed emotional facilities is kinda scary, perhaps like an alien child ("human-like feelings" with undeveloped reasoning, and the reasoning is undeveloped in ways we're not familiar with - at least I'm conjecturing that this machine will not be able to pass "the human children Turing test" any more than the adult version.) It's not clear what good you can do with such a machine.

All of the above from a serious angle and without dwelling on the joy of sexprs like (Feels (Feels (Feels (Object)))).

Erm... A shitton of tools. You roughly write and validate an HLL description, translate it to gates or more generally/correctly library cells and then place them and route the connecting wires. GDS-II has everything at an exact place, from that they make wafer masks. But each stage is many tools and it's not fully independent considerations.

Or you can use Chuck Moore's famous 500 lines of Forth to produce a chip for 180 nm that can't access DRAM and go on about everyone doing it wrong.

> Whoa - MIPS virtualised their message passing hardware? How?!

No, I meant to say that they simply obsoleted that part of their architecture when they added virtualization, because they couldn't virtualize it.

> Eg there was a brave attempt to parallelise the inner loop of bzip2 - which resists coarse parallelisation thanks to loop-carried dependencies - this way.

So you say you can do hardware-assisted message passing that can be virtualized and can speed up bzip2 by parallelizing? How few instructions per RPC call does it take for you to still be efficient vs today's software-based messaging? (This is getting fairly interesting and it should be particularly interesting to serious CPU vendors.)

Don't ask me, it was mostly luck in my case. In general I think in chips even more than elsewhere you want to work at a small place to get big responsibilities quickly, and from that angle, right now doesn't look like a great time to enter the industry, since FinFET mask costs are 10x what they used to be in bulk CMOS and so the expected payout needed to justify risking the capital went up a lot, so less projects starting small. Maybe if node shrinks stop and mask costs go back down and people will start making plenty of specialized lower-volume chips since you won't be able to win just by shrinking high-volume architectures, it will be a good time to enter the industry again.

Hey, chipmakers deserve more credit than that! I'm a chip architect and we license from IMG and we license IP from others as well, but then there's a shitton of work and plenty of things which can go wrong, costing loads of money and big delays. For those chip makers rolling their own IPs, this is rarely the biggest risk, the biggest risk is integrating everything into a working, marketable chip delivered more or less on time and within budget.

Incidentally, the reason why chip companies are worth so much more than IP companies is that the cost and risk of making chips is much larger. IP and chip companies are both fabless, if the costs and risks were about the same, then I don't see why profits wouldn't be about the same.

Now it could be that in this instance, marketability, schedule and budget weren't a particularly big deal, and maybe the performance is so bad that this in itself made a lot of problems disappear. But I think it's likely that someone still sweated quite some to make it work. (TFA claims they were the first to implement this CPU in silicon, BTW - again, could be easy enough if they didn't care about performance at all, or if Imagination did all the work on the synthesis scripts and the backend or held their hand, but if they wanted high performance and had to optimize synthesis and placement themselves, that's serious work. TSMC won't do it for you, either - they want a GDS-II file, and I don't think they outsourced the actual chip design.)

In itself, this single sentence is true about every country on Earth; what gives it meaning is the context where it's followed by heaps of praise of Western racial policies, the positive example against Russia's and others' negative examples. I think it is relevant that this contrast does not quite make sense. If you allow yourself to smear a society of 140 million people in a single sentence, perhaps your hundreds of pages summarizing a society 10x as large is also a bit of a smear.

BTW, from a brief glance at your comment history, most appear to have a strong anti-Chinese sentiment. I think that if you want to argue that the report is largely correct, it will be more interesting if you elaborate on that instead of talking about whatever I said in the grandparent comment.

I was at the time of writing and still am an accelerator architect and I'd gladly use someone's idea in a mass market product (ASIC) if they didn't mind. However, it is also true that working on any real product means that many valid ideas useful in some contexts will not be useful for me, and I guess this is true for many ideas for speeding up higher-level programming models, and perhaps it was misleading of me to fail to point this out. (As I said I don't love the tone of that article, it is unfortunately very effective as my articles written in that tone around 2008 tend to resurface more often than articles written in nicer, more balanced tone and with way more technical details from around say 2012-2013. What is my takeoff wrt future writing I'm still not quite sure.)

Virtualizable hardware-assisted message passing is awesome. (MIPS for instance had a big fat ISA extension for hardware-assisted message passing and cheap hardware multithreading which Linux couldn't use and they then threw out the window exactly when they introduced hardware virtualization of the entire set of processor resources.)

As to software-based queues dying a fiery death - in what scenarios? As I said in a sister comment, I (think that I) know that things work out in computational parallelism scenarios where many tasks are mapped onto a thread pool, TBB-style, that is, I don't think the hardware overhead is ridiculously large in these systems. Where do things go badly? 100K lightweight threads communicating via channels, Go-style?

I'm not sure whether today's coherent caches, atomic operations etc. are a poor fit for what you want to do leaving much room for improvement (I'm sure someone familiar with say the Go stack will be able to say more; I can say that for computational parallelism everything is fine with current hw but there 100K tasks would map to dozens of threads, tops and if you want 100K concurrent actors maybe things look differently, at any rate I don't see how the shared-nothing part creates a problem hardware can solve here, I think maybe there are problems in the (lots and lots of concurrent actors) part but I'm not sure.)

Incidentally, IMO shared-nothing is an inherently inefficient model for multiple actors cooperating to perform a single computation, and nothing done in hardware can fully eliminate the cost introduced by the model (and if something can be done is can be done by code analysis transforming the code into a more efficient shared memory model.) This is not to say that there's no value in such a system - far from it, just that it's a poor fit for something things which can only mapped onto it with some overhead that hardware cannot eliminate.

I think all of your points are very valid, but they're focusing on one part - virtual memory - which you suggest to remove (and this can be done today by not using that part of the hardware, and in this case the penalty of having that unused hardware is AFAIK fairly small.) My original point was that adding (or changing) hardware to accommodate HLLs is not going to buy you as much performance as people think, and this is focusing on a different part sw/hw boundary (basically what should compilers/interpreters/runtimes be doing vs what should be handled at the ISA level, versus your points which talk about what protection mechanisms we want and who among hardware, software and OS should do what here. I guess I should have said C/RISC and keep Unix/MMU out of it as I did in TFA.)

What will actually happen with protection mechanisms I don't know; certainly Unix-style mechanisms are used to ever more places with say HSA's idea of accelerators and CPUs being aware of the same virtual memory maps. Compatibility is a very strong force here. On the other hand there's a lot of stuff happening with the memory protection disabled as you described. My predictions here are going to be less educated than many others', to be honest, because I deal with embedded systems whereas most of the exciting stuff here happens in servers, I'd guess (but I can tell that in automotive embedded systems of all places not only do Unix-style processes gain traction right now but so do hypervisors with actual multiple OSes, some of them POSIXy, sharing chips. So this is a data point showing a trend in the "more of the same" direction.)

OK Cupid blocked Firefox, a non-profit with less questionable business practices than most tech companies and certainly Uber, over Eich's quiet private donation which ought to be a smaller deal than systematic sexual harassment with consequences for victims instead of perpetrators (although the donation was proven while the harassment is alleged; I doubt this tips the scales of public sentiment though.) The overall reaction on HN was mostly positive. I'm sure an Uber boycott can be figured out. (Is it a good idea? I dunno, in Eich's case the question is different from this case and there's much to discuss, I'm just saying that people these days are fairly eager to boycott and fairly good at it once the proper mood sets in.)

I used that as an example of a bad idea; I don't have details on this bad idea but you could have an instruction looking at an init, bound and increment registers and a constant telling where the loop ends and voila, the processor runs for loops without needing lower-level increment and branch instructions, and it shaves off one instruction (not a cycle, necessarily, but an instruction):

    FOR counter_reg, init_val_reg, bound_reg, step_reg, END_OF_LOOP
    ...
  END_OF_LOOP:

...instead of:

    MOVE counter_reg, init_val_reg
  START_OF_LOOP:
    ...
    ADD counter_reg, step
    BRANCH_LESS_THAN counter_reg, bound_reg, START_OF_LOOP

I was saying that this obviously not-so-good idea is not much different in spirit from building hardware for quickly creating and applying lambda terms, which is what the Reduceron does. Lowering lambda calculus to simpler operations so that lambda expressions are not represented in a runtime data structure at all much of the time, the way GHC and other compilers approach the problem, is a better idea.

Well, yeah, but here the entire discussion is about UK's exit from the EU, at which point freedom of movement in the EU doesn't apply, I think. So I was describing a hypothetical future situation where you would have some "stuff" to deal with.

These can be valid points for some, and carry less weight for others (say, if you live in Paris and are offered a good job in London, and they help you deal with the visa stuff, for most it's probably also nice to be able to visit Paris much more easily than you could from NY or SF.)

At any rate, "not sure why anyone would prefer London with the post-EU laws" is very different from "they decided they don't want me because they're not in the EU (even though there might be an otherwise nicely sounding arrangement available for me)."

"This country has decided they don't need you and me, they don't deserve our labour, our ideas and our taxes."

What about an EU citizen deciding to move to the US, Canada, Australia, Brazil or India? These countries were never in the EU. Did they therefore decide they don't need EU citizens? If not, why is the UK after it exits from the EU necessarily a less welcoming place for EU citizens than other non-EU countries?

It is not obvious to me that a compiler or JITter can generate low level code that is (A) free of bugs (compilers are notoriously buggy, as in hundreds of real bugs found by a single fuzzer like CSmith) and I don't want those bugs to hose my filesystem as it could on DOS machines, and (B) always as efficient as lower-level code. MS for instance did interesting experiments with removing virtual memory and I'm not saying it's necessarily a bad idea, just that it saves you very little and the real-world risks are higher than the theoretical risks.

Shared memory multithreading is fastest because explicitly communicating all of your tasks' inputs and outputs without any caching will transfer more data than using caches where several tasks can read the same thing from the same place. Cache coherence is not only built on shared nothing-message-passing under the hood, it's built on caches. If you cache your messages/accesses/whatever somewhere, you'll have coherence problems, if you don't, you'll have efficiency problems.

Just because you have a language with a native primitive doesn't mean this language doesn't throw efficiency out the window by building things around this primitive. Say, plenty of languages have cons cells for all the wrong reasons (I think Clojure is the one language that escaped this in its lineage) and still cons sells are fundamentally inefficient no matter what you do in hardware, this part I elaborated on in TFA. Just like having a language with a primitive solving the halting problem doesn't solve the halting problem, you can't have a language with arbitrary primitives and a magic machine making the sw+hw system as efficient as any alternative.