Tobba_ · HackerTrans

"swarm" means large numbers by definition, otherwise you have... well, plain-old coordination. Large numbers of F-35-sized aircraft is flaunting economics in the face a quite a bit (so I'm sure the US military loves the idea).

Tobba_

8 anni fadiscuss

The idea of drone swarms doesn't go well together with aerodynamics and basic physical intuition. If you shrink an aircraft down, the aerodynamic cross-section (i.e the drag force) scales with the area (scale^2), but your engine thrust is going to drop roughly by the decrease in volume (scale^3).

So you end up losing maximum airspeed and fuel efficiency (in terms of the mass you're moving) the smaller you go. Unless the drones in your swarm were really big, it doesn't work out.

Although, I imagine we'll see some smaller, unmanned jet fighters in the future (assuming someone figures out how to control something like that remotely, or autonomously). A smaller aircraft has the advantage of a smaller radar cross-section and being more difficult to hit. Doing away with the pilot cuts out a lot of weight and frees up room for a larger engine and fuel tank, offseting the downsides of the smaller size somewhat. There should be a sweet spot where that works out.

Tobba_

8 anni fadiscuss

On Win10 you need to have enough swap space on an SSD; HDD I/O has totally kneecapped latency, seemingly due to blind usage of NCQ (AHCI driver got replaced from Win7), so it chokes out entirely when combined with the even more broken swap manager.

"Enough" meaning "infinite", because you're going to have something leaking all that memory. Task manager doesn't even show memory usage by default (add the "commit size" field), only the working set (and the swapping is insanely aggressive, so memory leaks just don't show up). Nobody seems to actually check that; even built-in stuff like Windows Update leaks pretty badly.

Oh and the memory accounting doesn't even work.

Tobba_

8 anni fadiscuss

Why the hell does RSA ever get used anymore, esp. in smartcards etc? It's been obsolete for like 10 years thanks to ECC, and ECC is way easier to implement (esp. 127-bit and 521-bit).

Tobba_

8 anni fadiscuss

Wouldn't code instrumentation be trivially bypassable using an eval construct? esp. something like

  []["constructor"]["constructor"]("while (true) { }")()

Or does Nashorn have a mechanism for forcing the code static?

Tobba_

8 anni fadiscuss

Not necessarily, 1.3MJ (360 Wh; but screw that unit) of diesel isn't much of an explosive under normal circumstances. It really depends on the maximum power output under normal operation, and whether it can occur uncontrollably.

Tobba_

8 anni fadiscuss

Good.

Tobba_

8 anni fadiscuss

Windows 10 is borderline unusable due to it (it evicts RAM very aggressively to use as disk cache). Doesn't help that their IO scheduler is completely screwed up too (and they removed the ability to disable NCQ, so disk performance on HDDs is down the drain).

Tobba_

8 anni fadiscuss

On that subject, I'm curious whether there is any CPU out there that sets the overflow flag incorrectly when computing (-1) - n when n is the most negative number (which negates to itself, so implementing subtraction by simply negating the RHS and adding will screw up the flags).

Tobba_

8 anni fadiscuss

As far as I understand, what's happening is:

* There's an old feature which causes POP SS/MOV SS instructions to delay all interrupts until the next instruction has executed, to safely allow changing both SS and SP without an interrupt firing inbetween on a bad stack.

* If such an instruction itself causes an interrupt (by triggering a memory breakpoint through the debug registers), it is delayed (as intended).

* The delayed interrupt will fire after the second instruction even if the second instruction disabled interrupts.

* By means of the above, a MOV SS instruction triggering a #DB followed by an INT n instruction will cause the #DB exception to fire before the first instruction of the interrupt handler, even though this should be impossible (as entering the handlers sets IF=0, disabling interrupts).

* The OS #DB handler assumes GS has been fixed up by the previous interrupt handler, which in now under user control.

Tobba_

8 anni fadiscuss

To be fair, Intel docs are so consistently gibberish that it might as well be classified a separate language (similar to english, but only a quarter the information density).

In this case it seems they just didn't properly specify a piece of insane behaviour though. Hell, I'd consider it an outright CPU bug if I'm reading this right. Seemingly there's a "feature" where loading SS causes interrupts to be delayed until after the next instruction, even if the next instruction disables interrupts - so you can cause an interrupt to fire on the first instruction of the handler (where it should be impossible).

Tobba_

8 anni fadiscuss

It might still be possible. The JVM and .NET both have their speed annihilated by their awful choice of memory model.

Tobba_

8 anni fadiscuss

The secret to linear algebra is homogenous coordinates together the exterior algebra. plus matrices sprinkled in. If you use those for everything all your problems simply disappear.

Tobba_

8 anni fadiscuss

I'm not talking about the fundamentally misguided memory-distributed computing stuff, I mean "improve flexibility enough that you can bolt some additional units on as offload" (address translation in this case would take some work though). The magic of presenting software with a more or less monolithic core in this case is that you don't have that problem, since you can simply do it the usual way.

Also, I don't think the trouble with added complexity out of the hot path is any added latency, it's that they're needlessly burning up the thermal budget. Not that raising the voltage is the best way of increasing frequency, but it's sure to do so.

Tobba_

8 anni fadiscuss

I've heard a few times that the Cell wasn't all that bad in terms of performance, just very difficult to program. Not sure how true that is, but ostensibly the useability is just a tooling issue. Probably not a tooling issue that can be solved short-term though.

Tobba_

8 anni fadiscuss

It'll change if someone can manage to take the "central" out of the CPU internals. You don't necessarily need software to see anything other than a monolithic core, but having to plumb everything through one central execution unit is hugely inefficient, if anything due to the latency involved. For example, if you're performing an indirect load and hit DRAM while loading the pointer, that result has to be brought into the core, then all way back to the memory controller the same way it came. So far that's just been worked around by throwing in bigger and bigger caches, but the size of first-level cache is at a dead end for now (due to needing physical proximity).

Heck, current x86 chips could be juiced quite a bit if you could take out the requirement for backwards compatibility. Instruction encoding being the obvious thing (not that it's not hip and RISC, but that it's an absolute mess that a huge proportion of the chips power has to be wasted on, and is pretty space-inefficient due to how horribly allocated things are). Less obviously just removing things like the data stack instructions (which, at least on Intel, have a dedicated "stack engine" to optimize them), the ability to read/write instruction memory directly (creates a mess of self-modifying code detection to maintain correct behaviour, and complicates L1 cache coherency a bit). Trimming transistors reduces the power consumption, which in turn means you can raise the voltage without the chip melting, and can clear up space in your critical data path.

Tobba_

8 anni fadiscuss

Personally I'd predict the opposite (and current) pattern, creating generic chips which can replace many ASICs / less generic chips. If you can produce a chip which can replace 10 other low/medium-volume designs, economical scaling will win out as long as you're not adding too much overhead. This has been driving FPGAs forward for quite some time, although they're inherently pretty inefficient in terms of die size. Plus, it also provides some logistical advantages in terms of supply chain fragility.

See also: how ridiculously cheap microcontrollers have gotten, and the current messy DRAM pricing (high-capacity chips used in phones sometimes ending up cheaper than low-performance/capacity chips).

Tobba_

8 anni fadiscuss

GaAs logic is probably happening at some point, just not yet. All improvements like that which would be incredibly expensive to develop will be held off on until all cheaper options have been exhausted. It does seem to be slowly moving though.

Tobba_

8 anni fadiscuss

Seems like most people here are bringing up speed of light problems, which are a concern, but it's not what stops you. The problem is that your yield goes down exponentially with die size, and binning them becomes a clusterfuck. The opposite direction of making smaller dies is fairly attractive though. For example, AMD split Threadripper into multiple dies on an MCM and seem to be saving a fortune on it, at the expense of some die area for interconnects. That way they can test and bin dies individually an assemble an MCM of known-good dies from the same bin.

I remember reading that GPUs are getting to fairly monsterous die sizes though - and they're paying for it.

Tobba_

8 anni fadiscuss

I think we're far from the ceiling on CPU performance so far, but we seem to have hit a (micro)architectural dead end. Currently a lot of time and transistors is spent simply shuffling data around the chip, or between the CPU and memory, while the actual computational units simply sit idle. Or similarily, units that sit idle because they can't be used for the current task, even if they should be - the FPUs on modern x86 cores are a pretty good example of this. FP operations are just fused integer/fixed-point operations, but it's been designed into a corner where it has to be a special unit to deal with all the crap quickly.

We've probably optimized silicon transistors to death though; that's why it's coming to a stop now. GaAs or SiGe are some of the alternatives there. Although there's still quite a lot of advancements there that simply aren't economical yet. For example, SOI processes at low feature sizes seem to be suitable for mass-produced chips now, but it hasn't made it out of the low-power segment yet. MRAM seems to be viable and might be able to provide us with bigger caches (in the same die area), but right now it's mainly used to replace small flash memories (plus some more novel things like non-volatile write buffers, but it's horrifically expensive). So we've probably got a few big boosts left there, but it's not gonna last forever.

The next obvious architectural advancement right now is asynchronous logic. In theory, it's superior in every way - power and timing noise immunity, speed isn't limited by the worst-case timings, no/reduced unnecessary switching (i.e lower power, meaning higher voltages without the chip melting itself). On paper, you run into some big problems on the data path - quasi-delay-insensitive circuits need a lot more transistors and wires, and the current alternative is to use a separate delay path to time the operations, which is a bit iffy. You do at least get rid of the Lovecraftian clock distribution tree that's getting problematic for current synchronous logic. In practice, the tools to work with it and engineers/designers that know how to work it don't exist, and the architecture is entirely up in the air. So it's many years of development behind right now and a huge investment that nobody really bothered with while they could just juice the microarchitecture and physical implementation.

comments