3,339 karma · joined March 24, 2011
Having the population located in dense urban areas is more efficient and therefore cheaper in terms of the real resources that are required: infrastructure is cheaper to build, distances are smaller so that less time is wasted commuting and transport is cheaper (not to mention that highly efficient public transport becomes viable).
So in real resource terms, urban sprawl is more expensive.
But since land is still a limitation and zero-sum, competition can drive up housing costs in attractive dense urban areas to the point where it more than cancels out the efficiency gains of the urban density, and the cost of living in the urban area to the individual becomes higher than the sprawl.
This is why some sort of collective planning is required to make sure that as much as possible of the efficiency gains of urbanization are actually realized. This means having proper infrastructure mostly in terms of public transport.
(Of course, the other part of it is that you need to be careful not to look at just housing costs in the first place. For example, I don't even have to pay for a car, and I benefit from city infrastructure in many other ways.)
This kind of motivation has arguably always been about people misunderstanding economics. In this particular quote: government bailouts are not a function of the exact mechanisms of the currency, but of whether you elect politicians that want to keep banks in check or not. Even if everybody used Bitcoin, a certain type of politician would still be tempted to do bank bailouts.
> - has a limit on maximum amount of currency that can exist (so it is free of inflation)
And this is actually an anti-feature.
It should be obvious that relative prices need to be able to adjust in order for markets to function well, and if you look at economic history without ideological blinders, it becomes clear that there are many important markets in which absolute prices move up more easily than they move down, notably but not only wages and salaries.[0]
Having a modest amount of inflation means that the absolute price that you as a seller can earn must increase if you want your relative price to be stable - a kind of economic Red Queen hypothesis. This makes it easier for relative prices to adjust downwards, which is good for the functioning of markets.
The economics behind Bitcoin has always been a bad idea.
[0] There are good reasons for this. In order to improve your financial position, you have to reduce your monetary outflows or increase your monetary incomes. The amount of effort you spend is proportional to the number of contracts you negotiate, not to the value of those contracts. So if you have many monetary outflows, but comparatively fewer (but larger) monetary incomes, then you'll rationally focus your efforts on increasing those incomes (or fighting against decreases of those incomes). Almost every household, and many companies, are in the position of having fewer incomes than outflows, so they all have an incentive to fight relatively harder against price decreases on their income. Which has the net effect that absolute prices move upwards more easily than they move downwards.
Obviously a day may come where people plug their phones into docking stations that are equipped with a keyboard and a monitor, but it seems likely that we'll stick to lightweight laptops for a long time.
The distinction of "legal tender" is that (1) the state expects payment in the domestic currency and (2) when there is a dispute in court, any fines or financial penalties will have to be paid in the domestic currency.
This does mean that if you enter a contract which states that some payment has to be made in a foreign currency, a court can overrule this and force the payment to be made in the domestic currency instead. That basically never happens in practice, but it is possible.
As to why governments don't forbid Bitcoin & friends: in the larger economy, they just don't matter, so why bother? Now the ICO craze has caught attention because of securities fraud, and governments have stepped in.
Even during the period of largely unregulated private banking that reached its peak in the 19th century, the private banks largely just issued paper money that was denominated in coins that were issued by governments.
For various reasons I still suspect that some other factor is at play, but I also don't really know how to tease that out. Maybe there are some performance counters one could look at, but I'm just speculating.
> As such, the optimal spinlock implementation on x86 doesn't use the LOCK prefix at all! You rely upon the memory-ordering consistently guaranteed by the x86 processor, and let the cache-coherence mechanism handle everything for you.
That's just not true. Spinlocks are not magic; they need to be implemented, and all the implementations I know of use a (atomic and therefore locked!) cmpxchg.
Which makes sense. Spinlocks are a synchronization primitive, and you wrote yourself that ALL synchronization primitives on x86 are "LOCK" prefixed.
So let's rephrase the original question: why should a locked cmpxchg + additional memory accesses be more efficient than a single locked increment?
Can anybody actually explain this result? The spinlock needs at least one atomic operation and a write (for lock + unlock) and one non-atomic read-modify-write per iteration while the atomic increment needs only a single atomic operation per iteration and no other memory access. How on Earth can the latter variant be slower?
The only thing I can think of right now is that due to some micro-architectural idiosyncracies, the relevant cache lines end up migrating between cores more often in the atomic increment case, while in the spinlock case, the same core ends up winning the lock back-to-back more often (and so cachelines migrate less frequently which reduces the overall running time).
That seems like it would most likely only ever be relevant to this kind of extremely micro benchmark, but I'd be interested to hear if there are other explanations (I haven't watched the whole talk, but at least the slides don't seem to make an attempt to explain this).
Is this kind of hyperbole really necessary?
Also, as a sibling comment mentions, the 10x claim is pretty disingenuous in the first place.
It's just that there are a lot of branches that don't depend on untrusted data. Speculatively executing past them is perfectly fine and extremely valuable for performance. That's why nobody wants to get rid of speculative execution.
Keep in mind that it's not just the L1 cache you potentially need to worry about, but also all the higher level caches, which are really like remote nodes in a distributed system. Even the last level cache would have to be aware of the current speculation state of all threads in the system, which seems like it would be really expensive.
What's perhaps even worse, you wouldn't be able to hit on speculatively loaded cache lines until they have "committed" (because the resulting change in external bandwidth utilization may be observable from another thread), which would probably kill a lot of the benefits of the cache in the first place.
I take it you don't really read a lot of Linus' mail? I find it hard to believe that somebody would think that, unless they only got to see a highly biased selection of his emails.
Also, consider that we would never have had this thread in which several people are learning about gcc's documented behavior on unions if it hadn't been for the somewhat strong language. It serves a genuine purpose.
Interestingly, posits as originally proposed do have this property (except for infinity).
That's not what the article is saying. The article is not saying that Kara being offended is smart and socially conscious. The article does not judge whether being offended here is smart or stupid or whatever.
What the article is saying is that it is smart and socially conscious to be aware of the fact that Kara is likely going to be offended. It is certainly true that awareness of others' likely reactions is smart and socially conscious.
The rest of your comment is pretty much a restatement of the conclusion of the article :)
[0] http://www.johngustafson.net/pdfs/BeatingFloatingPoint.pdf [1] http://nhaehnle.blogspot.de/2017/09/posits.html
In this particular case:
> Any country that suddenly declared it had more money than all the others combined and was now buying up all the available land on the planet would find themselves in a heap of trouble. Trust still has to be earned & maintained
... why not be more specific and say that if a country did that, its currency would immediately drop in value on the foreign exchange markets.
Anyway, I'm not saying that trust is irrelevant, and I do largely agree with you, I just think it tends to be overrated in these kinds of discussions.
The point is that in the typical political discourse, people extrapolate their own personal experience to government. They seem to think that if the government spends too much, then at some point it will literally be unable to spend more -- and that's just wrong.
Inflation doesn't change that. Inflation is simply the answer to the obvious question that comes next. After all when you tell people the truth that government has no limit to how much it can spend, they tend to become understandably suspicious. TANSTAAFL and all that.
Inflation doesn't affect how much money the government is able to spend, but it does affect whether more (net) spending is a good idea, so it is a constraint in that sense. But it's qualitatively very different from the entirely fictional budget constraint that most people seem to be worried about.
I think it's very important for us to be aware that while this is true for private individuals, companies, and local governments, it is totally false for monetarily sovereign governments like the US federal government.
There is no limit to how much money it can spend. Any discussion of budgets at that level in terms of deficits etc. is completely flawed, and not just because a lot of politicians are extremely hypocritical about it, but because it just makes no sense in terms of economics and finance.
When thinking about the spending and taxation of a monetarily sovereign governments, the only real constraint is inflation. This is because the only real constraint is the amount of real resources that are available.
For what it's worth, this approach is part of what's called "functional finance".
No matter how you do it[0], alignment is bad for maintainability. It happens that someType or someFunctionName changes, and if you use alignment, you'll have to re-align all those parameters. This is annoying to do even with editor help, and it generates noisy diffs which make patch review needlessly more difficult. Aligning the names of member variables is even worse.
Just Say No to alignment, perhaps? ;)
[0] Well, except if you use "elastic tabs", which don't have widespread support in the first place.
Even somebody who is familiar with the concept of man pages would have no chance of knowing that xset is the one to look for.
Discoverability is super important. Luckily, the kind of desktops people actually use tend to have a System Settings app in which mouse acceleration can be figured.
Spectre 2 is about code in a less trusted domain A introducing an otherwise impossible branch target used by branch prediction on code in a trusted domain B. So a solution that adds tag bits to the BTB to distinguish between those domains should be a 100% effective fix. The only arguments are about how many tag bits & who gets to set them, i.e. a user-mode JIT sandbox would want to be able to control at least one tag bit for this, but if it can, it'd be fully effective.
Unless you start thinking about protecting different JITted code domains in the same address space from each other... I guess at some point you just have to bite the bullet and invalidate the BTB.
I suppose an additional problem would be if the BTB just "hallucinated" random indirect branch target destinations somehow, which could allow untrusted domain A code to jump (in speculation) to code that would normally be unreachable. A kind of "reverse Spectre 2", if you will, although the same tag approach should fix that at the same time as the original Spectre 2.
Spectre 1 attacks from JIT'ed code against the outside code are definitely possible though.
Ideally the ISA would allow user level code to also toggle a flag that affects the BTB. That would allow embedding JIT code while guarding against Spectre 2 (fixing the BTB injection).
I don't think you really need more than that though. Reading arbitrary memory would seem to require a Spectre 1-type attack instead. Unless you have an explicit counterexample in mind?
For the JIT'ed code, Spectre 1 can probably be mostly avoided using the bitmask trick or something equivalent, which we seem to be moving in the direction of anyway (thinking about the WASM execution environment specifically), and for the "host" code inside the sandbox, the same kind of selective software fixes are required as in the kernel.
For Meltdown, you need to just never load data from L1$ when permissions checks fail. Since address translation is already on the L1$, doing permissions checks there as well is not a big burden. This is quite natural to do, and also why Meltdown specifically affected Intel, and not everybody.
For Spectre 2, you need to add some bits to the branch target buffer to tag entries by the privilege level and ideally PCID (to protect user level processes from each other). And then you just don't use BTB entries with the wrong tag.
It'd still be interesting to know the details, e.g. what exactly they changed for Spectre 2.
As for the alternatives to asymmetric crypto: I like lattices, I've studied them a lot myself, though not in a crypto context. But have you looked at the required key sizes of those alternative schemes? They're pretty horrible and not at all comparable to what we have today.
Obviously people will continue research on this, and perhaps something close to elliptic curves in terms of efficiency will be found. I certainly hope so, but I'm not holding my breath.
I agree that archived traffic is an issue as well, but personally I'm more worried about the future than the past.