_yosefk

I'm selfish enough, but I'm not sure how enjoyable it would be once I reach 130, not to mention 1300, on the theory that even if much of the physical aging problem is solved, much of the mental aging problem will remain, and the same things making me increasingly mentally inflexible will make it all increasingly less fun.

I also think death is treated too seriously by people believing they're just a bunch of atoms but still thinking of themselves as an entity meaningfully separate from the rest of the world.

How about not bailing out private enterprises with public money? That'd cost Buffet a few tens of billions.

Humanity being its own only remotely dangerous enemy, I never understood how more planets help.

For (1) does this mean that everything in the global namespace barfs when called from a worker thread?

(2) sounds like it might need a larger set of primitives, though I'm not sure.

No manned flight to Mars in the next 10 years, I bet. (Why anyone would want that escapes me... Then again that is why I will be wrong, if indeed I will be.)

I'm curious about 2 things:

1. How is the accidental modification of random JS objects from multiple threads prevented - that is, how is the communication restricted to explicitly shared memory? Is it done by using OS process underneath?

2. Exposing atomics greatly diminishes the effectiveness of automated race detection tools. Is there a specific rationale for not exposing an interface along the lines of Cilk instead - say, a parallel for loop and a parallel function call that can be waited for? The mandelbrot example looks like it could be handled just fine (meaning, just as efficiently and with a bit less code) with a parallel for loop with what OpenMP calls a dynamic scheduling policy (so an atomic counter hidden in its guts.)

There do exist tasks which can be handled more efficiently using raw atomics than using a Cilk-like interface, but in my experience they are the exception rather than the rule; on the other hand parallelism bugs are the rule rather than the exception, and so effective automated debugging tools are a godsend.

Cilk comes with great race detection tools and these can be developed for any system with a similar interface; the thing enabling this is that a Cilk program's task dependency graph is a fork-join graph, whereas with atomics it's a generic DAG and the number of task orderings an automated debugging tool has to try with a DAG is potentially very large, whereas with a fork-join graph it's always just two orderings. I wrote about it here http://yosefk.com/blog/checkedthreads-bug-free-shared-memory... - my point though isn't to plug my own Cilk knock-off that I present in that post but to elaborate on the benefits of a Cilk-like interface relatively to raw atomics.

It still matters if the error occurred when the life expectancy was 7 years or 7 months, so ideally you'd want to count that.

func<a,b>(c,d) isn't faster than func(a,b,c,d) if the compiler sees that a,b are constants and the call to func is in the same file as its definition; the only thing CPU+GPU code adds here relatively to CPU-only code is, perhaps you need to write a wrapper along the lines of func_ab(c,d) { func(a,b,c,d) }, a bit ugly but the code is still pretty simple and maintainable. (And unlike the case with templates at least you can make sense of the symbol table etc. etc.)

As to runtime errors because of misspelling a parameter name, this is going to be fixed the first time you run the program and you live happily ever after; I don't mind these errors in Python very much and I don't mind it in C programs using strings to refer to variable names in whatever context that may happen.

Overall the amount of "dynamism" in CPU/GPU programming IMO does not result in wasting almost any optimization opportunities nor does it make the program significantly harder to get right, but I'm prepared to change my mind given counterexamples (certainly in Python it's really easy to demonstrate missed optimization opportunities relatively to C due to its dynamism... The amount of dynamism in CPU/GPU programming however is IMO trivial and hence the issues resulting from it are also rather trivial.)

OpenCL was moving to LLVM IR away from programs-as-source-code-strings at some point. Still, you ought to have a JIT step if you want to be able to ship the same binary to multiple systems with GPUs not compatible at the binary level. And BTW shipping LLVM IR on the CPU would make things better in terms of supporting CPUs with incompatible ISAs... whether that ever overtakes native binaries is a question (it did to an extent, of course, with the JVM and what-not.) Of course you could move the JIT off the client device completely and do it at the App Store - prepare a bunch of binaries for all the devices out there - but still, the developers will have shipped IR.

Once you get to shipping IR instead of strings, which is nice I guess in that it should make initialization somewhat faster and the GPU drivers somewhat smaller, I'm not sure what you're going to get from being able to treat a CPU/GPU program as a single whole. Typically the stuff running on the GPU or any other sort of accelerator does not call back into the CPU - these are "leaf functions", optimized as a separate program, pretty much. I guess it'd be nice to be able to optimize a given call to such a function automatically ("here the CPU passes a constant so let's constant-fold all this stuff over here.") The same effect can be achieved today by creating a GPU wrapper code passing the constants and having the CPU call that, avoiding this doesn't sound like a huge deal. Other than that, what big improvement opportunities am I missing due to the CPU compiler not caring what the GPU compiler is doing and what code the GPU is running?

(Not a rhetorical question, I expect to be missing something; I work on accelerator design but I haven't ever thought very deeply about an integrated CPU+accelerator compiler, except for a high-level language producing code for both the CPU and some accelerators - but this is a different situation, and there you don't care what say OpenGL or OpenCL do, you generate both and you're the compiler and you use whatever opportunities for program analysis that your higher level language gives you. Here I think the point was that we miss opportunities due to not having a single compiler analyzing our C/C++ CPU code and our shader/OpenCL/... code as a single whole - it's this area where I don't see a lot of missed opportunities and asking where I'm wrong.)

Keeping it simple works wonders but you can't do it alone. A language with a culture of making things complex so as to achieve some standard of perfection, and/or with many developers simply not knowing how to stay out of trouble and not being able to tell what's fragile and what's trustworthy, will make it harder to "keep it simple."

I agree that when programming mostly alone one can get by very nicely in any reasonably popular language since its popularity necessarily means that it's workable in the areas where it's typically used. I disagree that languages can not get in your way if you know what you're doing once you're not doing it alone.

Governments could have criminalized it at any point, they can criminalize it now, and they will certainly criminalize it in the future if they feel a need to do so (unless this thing gets used by >1% of the population which I'm willing to bet money against.) They didn't because they didn't want to. If they wanted to know who created Bitcoin in order to "torture" them they would have found out, at this point we know how good they are at this sort of thing; also, if they wanted to "torture" prominent people behind the Bitcoin software there was never a shortage of people with known identities. That he didn't pay his taxes seems to be a separate issue.

Adapteva has done chips for <$2M AFAIK, definitely <$5M, at 28 nm. Of course few chips are like theirs in terms of design simplicity relatively to their large size except for bitcoin miners. For $10M however you should be able to do pretty big designs with lots of licensed IP, heavyweight simulation acceleration etc. A breakdown of real projects involves violating NDAs.

Below 28nm their numbers become really deranged. This overstatement is IMO peddled by big name chip companies trying to convince analysts that FinFET nodes give them a moat. In reality the end of Moore's law means they'll face vicious competition.

Of course nothing prevents you from spending huge amounts of money. Buy an ARM architecture license - there goes $30M and that's before you pay for developing your own ARM-compatible CPU.

Their figures for chip costs at all nodes are bullshit including the $30M/chip at 28nm figure. It's inflated out of all proportion and of course it depends tremendously on what you are doing.

A lot of researchers do make their results available as code and a whole lot of those who don't actually publish lies, as many people in academia from grad students to professors who implemented research papers and observed that the algorithms don't really work discovered.

File paths and manual steps can be worked around, mobody said it should build and run painlessly forever after having been published on any future system with no tweaking and with the researcher indefinitely maintaining the program. If however nothing remotely close to a working state can be published it's not a great sign.

All of these companies sell many different products and I'd guess that their reported overall gross margins will be different from the margins of any given product. For instance, I rather doubt that either TSMC or Samsung get 50% margins when making Apple's chips.

GPUs and FPGAs are very far from each other architecturally and are good at very different things. They will certainly be separate products for the next 3 decades as they were for the last 3 decades.

The thing is, it's not gonna help to have a "Steve Jobs" nor will any degree of understanding the competition help if you're used to ship an expensive high-margin product and along comes a low-margin competitor. Neither ARM nor TSMC attempt to make the kind of profit that Intel is used to making and this is the real problem for Intel; even if it wins 75% of the mobile market by shipping adequate chips at adequate prices, the profits won't be anywhere near what it gets in the PC market. (Of course this is just as true about Apple as it is about Intel, and I think their latest quarter results testify to it just as much as Intel's. Actually, the surprising thing about Intel (which is not true about Apple, Steve Jobs and all) is the degree of their dominance in the market for anything resembling a PC - a computer where you can get work done; one might expect both AMD and non-x86-based workstation products to do better, certainly Android is a bigger threat to iPhone/iPad than any competitor ever was to Intel in the PC space.)

The trouble is that a union can gut many kinds of businesses since all the workers can not be replaced without greatly and often fatally disrupting the business, and then if an industry is unionized, workers become a monopoly and this can result in large deadweight losses for the economy; this is not to say that without unions everything works out perfectly, just that unions have their problems.

A nice quote:

"In 2012, staff at the Federal Trade Commission recommended filing antitrust charges after determining that Google was engaging in anti-competitive tactics and abusing its monopoly. A staff report that was later leaked said Google’s conduct “has resulted — and will result — in real harm to consumers and to innovation in the online search and advertising markets.”

The Wall Street Journal noted that Google’s White House visits increased right around that time. And in 2013, the presidentially appointed commissioners of the FTC overrode their staff, voting unanimously not to file any charges."

Is there that big a difference between inflating stock prices the way the BOJ does and depressing bond yields through "normal QE" (which amounts to buying bonds, thus inflating their prices)? Depressing bond yields distorts the market in the sense of encouraging risky investment/"risk mispricing", and then indirectly it inflates stock prices as investors' safe alternatives now yield less income.

I dunno, KDevelop 4, based on KDE's rather than Gnome's libraries, was nothing like KDevelop 3 and couldn't do some of the old things, and there was no way you could compile KDevelop 3 on an Ubuntu box bundled with KDevelop 4 and the new KDE libraries unless you were really good at this shit. Eclipse, based on the JVM, had a popular plugin that was broken, I think, in Juno or a bit earlier, and whose author refused to update it for the new Eclipse because too much of the things in Eclipse he depended on changed. Upgrading Emacs broke everyone's emacs-lisp hacks that they copied from each other. And so forth.

I think that in the land of Linux, the only things which remain backward compatible are the kernel (if you want to run statically linked userland binaries - not if you want to run driver binaries) and the GNU userspace utitilies like sh and grep (though sh is bash on some distros and dash on others, breaking the very popular assumption that sh is in fact bash, and env might reside in either /bin/env or /usr/bin/env, defeating its purpose of letting you deal with the fact that #!/bin/tcsh will break on systems keeping tcsh at /usr/bin. But a given distro will usually keep its shit where it last put it, which I guess is better than it could have been.)

It took me a while to decide to drive my own car, and one of the incidents prompting me to do it was when a taxi driver, having arrived at the destination (in this instance, the building where I worked), had walked out to urinate, right there on the sidewalk, in plain sight.

It's kinda sad how without personal accountability, that's the service that you get, and on the other hand, how Orwellian many of the ways to make workers accountable are.

If the government did nothing at all in the matter, I believe car companies wouldn't care less about emissions (though perhaps it would result in higher CO2 emissions but lower NOx emissions and perhaps that would have been a net benefit to society - but I'm not sure about that, so I wouldn't make an argument hinging on this being true.) Personally I would not advocate stripping the government of the power to regulate emissions (though I'm not at all sure how to get them to do their job properly), on the theory that with all the unintended consequences of regulation including higher NOx emissions, it's still better than nothing. But I have a feeling that jailing regulators is a promising approach to improving future regulators' performance, and this approach seems underrepresented in public discourse, perhaps because most people prefer to either abolish regulation altogether or to always blame the regulated industry. The main reason I mentioned stripping regulators of their power is that this is the logical conclusion of the assumption that we should expect competent, honest regulators to fail to detect fraud at such a huge scale.

Using an abandoned free software project is rarely going to be much fun, either. In fact, using actively maintained free software projects is rarely much fun, since many of them tend to often abandon old features and introduce new incompatible ones, and you either have to keep using old versions of everything or update everything at once, breaking a ton of things. (Of course at times you're way better off with a free program than you'd be with a proprietary alternative, but the reverse can be true just as much in other cases.)

Not acting quickly enough?.. VW's "defeat device" wasn't uncovered by the government, and it's been deployed for years. I'm not sure what would make governments do anything about this at any future point in time if the issue wasn't reported by a non-government entity. The article also elaborates the measures governments are taking to let perpetrators get away with this into the future (and another source reported how governments keep postponing random checks of cars on actual roads.) There are at least three reasons for governments to side with the perpetrators - campaign contributions or outright bribes to politicians, concerns about the economy/employment, and a revolving door between car makers and regulatory agencies, all this is true for any big business regulated by the government.

The belief that fraud is conducted on this scale but the regulator is not to blame is stunning to me (same with banking fraud etc.) I didn't say governments should necessarily be stripped of this power, just that if they all fail so miserably at something, you ought to either suggest that they cannot ever succeed (and if so of course you'll want to strip them of this power) or that people currently employed by governments to oversee this should be investigated, in the hope that eventually the governments can be trained to find competent people to fill these roles, and find some mechanism that prevents corrupting these people. Meeting extreme government incompetence with complete understanding ("they just didn't act quickly enough") and zero penalties, however, is IMO perpetuating the problem.

"Unlike other parts of the world, European nations incentivised the use of diesel vehicles over the last 20 years because they emit less carbon dioxide per mile than petrol cars. Governments thought stricter regulation would sharply reduce NOx emissions, but carmakers found ways around the rules and governments failed to clamp down on the practices."

How typical in so many ways (I particularly like the claim that governments "failed" without either suggesting to strip the governments of those powers which they failed to use so consistently throughout all of Europe, or charging government officials with criminal incompetence or fraud.)

Domestic animals are more successful right now than the humans breeding them if we count the total mass of organisms sharing similar genes; which IMO simply demonstrates the absurdity of much of our thinking about evolution in terms of winners and losers. (Another example - if you look at "evolutionary success" as the prevalence of patterns in general and not necessarily genes, then simple molecules like H2O are infinitely more successful/prevalent in terms of their total mass than any kind of a living organism, which means that the best way to win the evolution game is not to play. If we think of evolution as a game where winning equals maximizing the number of times a pattern appears in the physical space, then it ought to be one of the stupidest and most pointless games ever.)

Kinda depends on the cost of an error vs the cost of a slowdown though, and then there's a big difference between say Objective-C or the once-relevant COM/ATL etc. by MS, where you have all the C bugs and manual memory management plus somewhat automated memory management in some places with all the troubles of that, and say Java where at least you have a fully working garbage collector which deals with cycles and never leaks unreachable memory, and you also have guaranteed memory safety.

I'd rather trust my credit card number to a Java program than a C/C++ program - or an Objective-C program; see also http://www.flownet.com/ron/xooglers.pdf for the early Google billing server disaster, not possible with a garbage collector "thinking" about proper memory management and rather hard to prevent with very good developers thinking that they have thought proper memory management through. (And git had a bug where you could execute code remotely because nobody can really manage memory in C, etc. etc. etc.)

What if it's simply bribes and he won't say it because they will eat him alive? "Tarnished concept of government blah blah" sounds great to those who love the concept while not exposing this guy to libel lawsuits from the people put by this concept into positions to take the bribes.

Sure there are worse sites - I wasn't 100% serious there...