Man, you're so right: Fox News will totally sabotage Obama's re-election chances over this! News of the complete disaster which is the president's foreign policy will be bumped below the fold for 24-hour coverage of "office no one cares about"!

No one in either party's base gives a fuck about the gender or orientation of the holder of some office they've never heard of and will never care about. Maybe a few geeks care about this? Maybe?

Fanning the flames only makes it worse, is the thing. To most people, left and right, it simply doesn't matter. Let it be. Deny the stage those who want your gender or whatever the only thing that's important about you. End the conversation, deflate the energy, lets things that shouldn't matter lie there and not matter.

no

Except it's not.

Except it is. Sorry. No one cares if Zoe Quinn sucks 37 dicks (in a row). A lot of people care if she's getting positive press from the owners of those dicks. (Not to mention the fact that she's being a huge hypocrite because by her own definition she raped her boyfriend by sleeping around.)

They handle them fine, detecting when you use hand signals to indicate intentions

So, a driverless car that can't handle rain or snow or recognize a pothole is going to be perfectly safe around pedestrians and bicyclists?

O-kay....

Stop yourself. Nobody reading Slashdot today will live to see ubiquitous driverless cars.

Google isn't detecting potholes? Back in 1985, we had that on our DARPA Grand Challenge vehicle. The LIDAR on top of the vehicle was generating a ground profile. This was for off-road driving, where that's essential. I'd assumed Google was doing that; they have a Velodyne laser scanner that provides enough information.

In traffic, sometimes you can't see a pothole because it's obscured by a vehicle ahead, but if the vehicle ahead doesn't change speed, direction, or attitude, it's probably safe to proceed over the ground it just covered. On high speed roads, you can't see distant potholes clearly because the angle is unfavorable, but if the road ahead looks like the near road, and the near road profiles OK with the LIDAR, the far road is probably good. That's what the Stanford team used to out-drive their LIDAR range. (We didn't do that and were limited to 17MPH).

Fixed road components should be handleable. People, bicycles, and animals are tough.

While all hard drives now do their own Hamming error correction (or something better), RAID2 is the same idea for "raw" storage that doesn't: you write explicit ECCs to redundant volumes to allow recovery from both drive loss and bad sectors.

RAID5 with modern drives gives all the same resiliency, as the drives do the block-level ECC themselves, so you never see RAID2. But for a pile of flash memory, that's the filesystem-level equivalent of PAR files.

Thanks - a real example! Wow, to me "300" does not sound like a large number for a computer. My mind boggles at how anyone could write code that bad - the AI must be written in some wildly inappropriate language? Or the developer just didn't care about perf and never got a bug assigned as they didn't QA at that scale? Nah, he got the bug and the game shipped with it, of course.

I've never seen a gaming-related benchmark where the slowest new desktop CPU you could buy wasn't "enough".

Can you give me an example of a modern game (other than minecraft) where the difference between 2x2 GHz and 8x4 GHz CPUs would be human-noticeable?

When I think "next gen games" I think games written for mobile platforms that look like flash games and would have run on my C64, What specifically did you have in mind?

No idea. I don't know if the instructions for computing PC-relative addresses in an ISA without an architectural PC are patentable. They also exist in RISC V (not sure which came first), so if they do then it's going to be a problem for Kriste et al. Nothing else in there is especially novel: like ARMv8, it's a nicely designed compilation target, but it doesn't do anything that's especially exciting.

I didn't look at the floating point stuff in much detail, so there may be something there, although the biggest changes in recent versions of the MIPS specs have been that they're more closely aligned with the IEEE floating point standards, so it's hard to imagine anything there.

The biggest difference between MIPS64r6 and ARMv8 is that the MIPS spec explicitly reserves some of the opcode space for vendor-specific extensions (we use this space, although our core predates the current spec - it's largely codifying existing opcode use). This allows, for example, Cavium to add custom instructions that are useful for network switches but not very useful for other things. ARMv8, in contrast, expects that any non-standard extensions are in the form of accelerator cores with a completely different ISA. This means that any code compiled for one ARMv8 core should run on any ARMv8 implementation, which is a big advantage. With MIPS, anything compiled for the core ISA should run everywhere, but people using custom variants (e.g. Cisco and Juniper, who use the Cavium parts in some of their products) will ship code that won't run on another vendors' chips.

Historically, this has been a problem for the MIPS ecosystem because each MIPS vendor has forked GCC and GNU binutils, hacked it up to support their extensions, but done so in a way that makes it impossible to merge the code upstream (because they've broken every other MIPS chip in the process) and left their customers with an ageing toolchain to deal with. I've been working with the Imagination guys to try to make sure that the code in LLVM is arranged in such a way that it's relatively easy to add vendor-specific extensions without breaking everything else.

Imagination doesn't currently have any 64-bit cores to license, but I expect that they will quite soon...

Assuming that your code doesn't do anything that is vaguely MIPS specific. If it is, then there is little benefit in using MIPS32r2 now - ARMv7 is likely to be closer than MIPS32r2 to MIPS32r6 in terms of compatibility with C (or higher-level language) source code compatibility.

Basically, because the MIPS ISA sucks as a compiler target. Delay slots are annoying and provide little benefit with modern microarchitectures. The only way to do PC-relative addressing is an ugly hack in the ABI, requiring that every call uses jalr with $t9 in the call, which means that you can't use bal for short calls. The lwl / lwr instructions for unaligned loads are just horrible and introduce nasty pipeline dependencies. The branch likely instructions are almost always misused, but as they're the only way of doing a branch without a delay slot there's often no alternative.

There's no price yet because they're giving away the first production run to people who are going to do interesting things with them. Unfortunately, this is a really bad time to do anything MIPS related (and I say this as someone who hacks on a MIPS IV compatible softcore and the LLVM MIPS back end). Imagination has just released the MIPS64r6 and MIPS32r6 specs. These are the biggest revisions to the MIPS ISA since MIPS III, which introduced 64-bit support. They've removed a load of legacy crap like the lwr and lwl instructions and the branch-likely instruction family and added things like compact (no delay slot) branch instructions, the requirement that hardware supports unaligned loads and stores (or, at least, that the OS traps and emulates them), and added much better support for PC-relative addressing. The result is a nice ISA, which is not backwards compatible with MIPS32r2 or MIPS64r2, the ISA that these boards use. Any investment in software for MIPS now is going to be wasted when products with the new ISA come out.

For building big C++ projects, as long as the disk (yay SSDs!) can keep up, you can throw as many cores as you can get at the compile step and get a speedup, then sit dependent on single-thread performance for the linking. I got a huge speedup going from a Core 2 Duo to a Sandy Bridge quad i7, then another noticeable speedup going to a Haswell i7 in my laptop. The laptop is now sufficiently fast that I do a lot more locally - previously I'd mostly work on a remote server with 32 cores, 256GB of RAM (and a 3TB mirrored ZFS array with a 512GB SSD for ZIL and L2ARC), but now the laptop is only about a factor of 2 slower in terms of build times, so for developing individual components (e.g. LLVM+Clang) I'll use the laptop and only build the complete system on the server.