Tobba_

"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).

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.

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.

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).

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

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

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.

Good.

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).

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).

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.

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).

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

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.

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.

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.

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.

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).

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.

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.

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.

If they do, whatever issues they're occupied with finding would call for an exorcism.

This is what happens when you don't have a QA department.

Probably not gonna have as much luck with the transparency at those thicknesses.

It could potentially allow you to stack 3 infront of eachother to render color instead of needing alternating colored subpixels.

Not sure if that would actually be useful for anything besides a density increase, but it could make color vector displays feasible.

My ass, mostly. I'm extrapolating based on monitor framerates and how accurately we can see the velocity of fast-moving objects, and that I can spot a timing difference of ~5ms reliably.

Human eyes are almost comparable in terms of a framerate based on the neuron spiking rates, which are somewhere over 250-500Hz max. Obviously that's not directly comparable though, but it gives an idea of how well we can deal with moving objects.

Yeah I'd be fairly concerned about them lying to or simply bribing the police too.

It essentially is. Even with that crappy autoexposure, she would probably be visible if the resolution and framerate wasn't terrible, and the compression hadn't taken out whatever detail remained.

If you wan't to compare against human "sample rate", it'd be equivalent to at least ~200 FPS (in order to get the same accuracy with a camera). Sure, the signal takes a moment to plumb its way through, but that's irrelevant to spotting objects.

If they're actually feeding data at 15 FPS into their ML model, then what the fuck were they expecting? Correlating movements at those framerates would be nigh-impossible.

Relying on ML for this is already comically irresponsible, but that'd just be ridiculous.

For reference, VSM/4MSM are a set of shadow mapping techniques that don't suffer from acne, at the cost of suffering from bleeding problems that also need biasing.

Shadows are probably one of the places where raytracing makes a lot of sense though. It's one of few shadow rendering techniques that don't blow a ton of precious fillrate, and it shouldn't take too many rays.

That's just because the industry is stuck using triangles in the art pipeline (and don't put in as much effort into the low-polys as they used to). If they were willing to use some variation of patch-based pipeline so that they could utilize the tessellation hardware that has existed for years, it wouldn't be a problem. I've heard artists are scared of it due to how amazingly awful some editors managed to make the NURBS editing experience, but with a decent editor it really wouldn't be a problem.

Sadly tessellation largely just gets used to screw over AMD performance (for those sweet Nvidia kickbacks; if you're wondering why some games like Crysis 2 tessellate flat surfaces into an insane number of polygons, this is why).