Actually, it isn't if the compiler can prove that the layout is not visible outside of the compilation unit. I did have a student work on this, but the performance gains were negligible in most C code because complex data structures tend to leak across compilation unit boundaries (this may be less true with LTO). Even then, if you can recognise data structures that are bad then you can probably teach programmers not to use them, or put them in a standard library where their implementations can be easily changed.

It's much more interesting in environments with on-the-fly compilation, because then you can adapt data structures to use. Even then, you can do it outside of the compiler (for example, the NeXT implementations of the Objective-C collection classes would switch between a few different internal representations based on the data that you put in them).

The second part is the important one. Neurones in the human brain have an average of 7,000 connections to other neurones. That's basically impossible to do on a silicon die, where you only have two dimensions to play with and paths can't cross - you end up needing to build very complex networks-on-chip to get anywhere close.

The tick/tock really tells you a lot about Intel's focus as a company. They're primarily a company that builds fabs and spends a lot on developing new process technology. Designing new processor architectures is something that they do almost as an afterthought. It tells you something about the skill of their design teams that AMD was able to be competitive for so long in spite of being 1-2 process generations behind Intel.

The Mill is interesting, but has a lot of limitations that are likely to shop up in general purpose code (e.g. try writing a signal handler, context switcher, or stack unwinder for The Mill and you'll have a lot of fun).

As to Transmeta, the company that bought them was nVidia. Their Project Denver chips use a lot of the Transmeta ideas. They're particularly interesting in terms of history, as the project was several years along before they decided on the ISA (they spent a while trying to license the relevant patents from Intel to build an x86 chip, failed and went with ARMv8 - which may end up being a strategic error for Intel). Unlike the Transmeta chips, it has a hardware ARM decoder that generates horribly inefficient VLIW instructions from ARM code. This helps alleviate the startup penalty that the older Transmeta chips had, where they had to JIT compile every instruction sequence the first time they encountered it and then run it from their translation cache. The nVidia chips can run the code as soon as they pull it into the instruction cache and can profile it before doing the translation.

Your request makes no sense. You can always fit more processing power in a big case with lots of cooling than in a small case with very limited airflow (and power constraints on the fans). And it's always going to be cheaper to produce chips that can consume more power and dissipate more heat than ones with similar performance but a lower power budget. The only reason that the prices have become so close is that laptop sales passed desktop sales some years ago and now the economies of scale are on the side of the mobile parts.

If you want a laptop with the power of a desktop, just wait a couple of years and you'll be able to buy a laptop with the power of this generation's desktops. Of course, desktops will be even faster by then.

Bullshit (and I say this as a compiler writer). Very few compilers do anything with data layout at all (some JVMs do, to a limited degree, because they live in a closed world) and none outside of a few research projects will replace one data structure with another. What compiler are you using that will replace and XOR linked list or a skip list with something more efficient?

The belief in the compiler as a magic box that can turn a crappy algorithm into a good one is one of the things that a computer science education is meant to disabuse students of.

What are you talking about?

No, it really doesn't. If anything it's more relevant in other languages. For example, the cost of moving values from integer to floating point register files is a significant determining factor in JavaScript compiler design. To take JavaScriptCore as an example, the typical instruction cache size was one of the key inputs into the design of the interpreter and baseline JIT - it's written in a portable macro assembly language with precisely two design goals: the interpreter must have precise control over stack layout (so that deoptimisation can work easily) and the interpreter must fit entirely in the instruction cache of a modern CPU. The baseline JIT works by constructing a sequence of (predictable, because they have static destinations) jumps to the relevant entry points into the interpreter for a bytecode sequence. Trying to do this without understanding a reasonable amount of computer architecture would lead to all sorts of issues.

Understanding how a transistor works requires quantum mechanics, but 'transistors are tiny magical switches' is enough to be able to understand how to build them up into gates, how to assemble gates into arithmetic, logic, and memory circuits, how to assemble those into pipelines, and so on.

Eventually you need quantum mechanics (or relativity, or both) to understand how anything works, but understanding the electron transfer involved in combustion is not essential to understanding how a car works. Computer science is all about building abstractions.

There are different degrees of knowledge. I don't think anyone can be a competent programmer without understanding things like caches, TLBs, and pipelines (and, in particular, branch prediction). These things have significant impacts on the performance of code - often a factor of ten. Trying to write software for some hypothetical abstract machine, rather than a real modern processor leaves you with something that has the CPU gently warming the room while it waits for data from RAM. For example, I've seen people who skipped that part of their education think that XOR linked lists and skip lists are still good data structures to use.

You're paraphrasing Dijkstra, but missing his point. Astronomers, in general, know a heck of a lot about optics. His point wasn't to excuse ignorance of how computers work (he worked on the design of the STANTEC ZEBRA and wrote an incredibly scathing review of the IBM1620, for example, so clearly knew his way around the design process), it was to point out that this is a building block.

I'd consider any computer science curriculum that doesn't cover logic gates up to building adders, the basics of pipelining, the memory hierarchy and virtual memory translation at a minimum to have seriously skimped over computer architecture. The better ones will include design and simulation (on FPGA if budgets permit) of a simple pipelined processor.

If you want to work on compilers or operating systems, to give just two examples, then you need a solid grasp of computer architecture.

Normally you have to pay back loans in the currency that they were given. If you only have another currency, then you have to find someone willing to exchange them. The exchange rate isn't likely to be very good for a little while. That said, it would probably be great for the Greek economy, as a very weak currency will make exports very easy for them.

The other problem that you're not mentioning is that, if Greece leaves the Euro then Putin will be very happy to extend trade deals to them to get around sanctions and to piss off Germany and no one wants Greece to become a satellite state of the new USSR.

The Eurozone might be able to absorb a Greek exit in purely financial terms, but in psychological terms it would be a disaster. If Greece leaves, then that provides a precedent for countries leaving. Investments in Euros are based on the premise that the Euro is backed by a large economic base and if countries can leave that base then there's a lot less of an incentive to use the Euro. That's likely to lead to a drop in liquidity in the rest of the Eurozone, which would make leaving an even more attractive bet for some of the weaker economies.

The current size of the human head is limited by the pelvic size of women (humans already have a fairly high rate of mortality among newborns and mothers for unaided births compared to other species as a result). A more interesting approach would be to delay the age at which the head stops growing, though that would also need extra skeletal scaffolding to carry the larger head around, improvements to the cardiopulmonary system to keep it supplied with blood, and so on. Basically, the human brain is about as big as you can get it with small incremental changes to a hominid - you're going to need more than a few tweaks to get it a lot bigger.

Oh, and this isn't Twitter. You don't need to say '@GloomE' - we can tell from the fact that you replied to his post that you replied to his post.

When TFT monitors were new, having a couple of stuck pixels was normal and manufacturers said up-front the number that they considered normal. Typically it was under five, but for some of the cheap panels it was more. Apple had a fairly complex policy (it depended where on the screen they were and stuck-on counted as worse than stuck-off). They would refuse to accept returns for stuck pixels if you had fewer than this number (although, in the UK at least, you could return without giving a reason under consumer protection laws and then get a new one).

By about 2005, dead pixels were mostly gone from things that made it to consumers, but 2000-2005 there was a gradually decreasing acceptance for them.