owlbite

That and the speed limits are actually enforced, at least significantly more so than they seem to be here in California:

- Lots more speed cameras

- Average speed cameras especially make a huge difference vs spot enforcement

- Tolerance for enforcement is normally 10% rather than 10 mph (i.e. 30 limit means no more than 33mph rather than no more than 40mph)

Which is still shockingly outdated compared to e.g. London, where I just use my tap to pay method of choice on entry and exit, done.

I think this is the thing we need to change most. These big companies effectively have as much power as courts to break your life, but no transparency, oversight, appeals process or even a clear process in some cases. They can destroy a person or a small business without even noticing.

So how many gates are we talking to factor some "cryptographically useful" number? Is there some pathway that makes quantum computers useful this century?

Trying to reduce high end processor performance to "operation X takes Y cycles" likely confuses the uninitiated more than it helps once you get beyond "cache miss bad".

For the uninitiated, most high-performance CPUs of recent years:

- Are massively out-of-order. It will run any operation that has all inputs satisfied in the next slot of the right type available.

- Have multiple functional units. A recent apple CPU can and will run 5+ different integer ops, 3+ load/stores and 3+ floating point ops per cycle if it can feed them all. And it may well do zero-cost register renames on the fly for "free".

- Functional units are pipelined, you can throw 1 op in the front end of the pipe each cycle, but the result sometimes isn't available for consumption until maybe 3-20 cycles later (latency depends on the type of the op and if it can bypass into the next op executed).

- They will speculate on branch results and if they get them wrong it needs to flush the pipeline and do the right thing.

- Assorted hazards may give +/- on the timing you might get in a different situation.

Whenever we make our code faster the users just run bigger models :P.

Having "Mathematics for Computer Science" as a course title rubs me the wrong way, I always believed Computer Science was a specialized subfield of Mathematics.

My policy: If it's a real TODO, it includes the ticket number/link tracking the actual fix. Otherwise it should either be a regular comment or not exist.

I suspect it comes from raising flags/signals (literally as one might run a flag up a flag pole?) to indicates CPU conditions, and then that terminology getting propagated from hw to sw.

So we write a lot of code in this agnostic fashion using typedef's and clang's vector attribute support, along with __builtin_shufflevector for all the permutations (something along similar lines to Apple's simd.h). It works pretty well in terms of not needing to memorize/lookup all the mnemonic intrinsics for a given platform, and letting regular arithmetic operations exist.

However, we still end up writing different code for different target SOCs, as the microarchitecture is different, and we want to maximize our throughput and take advantage of any ISA support for dedicated instructions / type support.

One big challenge is targeting in-order cores the compiler often does a terrible job of register allocation (we need to use pretty much all the architectural registers to allow for vector instruction latencies), so we find the model breaks down somewhat there as we have to drop to inline assembly.

They already are?

I mean, we could just throw them in jail and then sell their labor back to giant corporate entities for a fraction of minimum wage.

There is a significant asymmetry in the requirements: cheap attack drones only have to succeed once, cheap defense drones have to succeed every time (or intercept sufficiently far out that some more reliable backup can be deployed when they fail).

Most math is more about definition, proof and structuring/relationships than about numbers. It is a bit of a joke among math students that numbers above 5 are effectively infinity, they crop up that rarely.

Because that's worked so well for PCs?

The biggest contrast for me between Oxbridge and another red brick was the Oxbridge tutors aren't shy of saying "You've not done the homework, go away and stop wasting my time", whereas the red brick approach was to pick you up and carry you over the finishing line (at least until the hour was up).

Having been involved in UK research labs before moving to industry, none of this surprises me. The government is more interested in short term headlines than long-term actually doing something.

They'd rather make capital investments (which aren't a recurring budget line, so the same money can make different headlines next year) than pay for the sort of ongoing spend on paying experts competitive salaries to actually build a real capacity.

Prior to Turing Institute there was the Hartree Centre, which was hobbled from hiring anyone significant by being tied to a non-technical civil-service payspine that struggled to approach even "competent" level salaries for these positions as the posts didn't manage 100s of minions.

Our first family computer was an A3000. I'm still amazed at the boot time on it compared to the PCs we had later (even today). Switch it on, beep and then almost instantly you're in a responsive GUI. (The wonders of storing the OS in a ROM I guess).

I've also seen it explained that it's part of their toolset in extracting maximum "value" from a customer.

Richer customers self-select to pay higher prices without the app as they can't be bothered faffing around to find the digital coupon/deal/whatever combination (you can, of course, only use one of the wide range of deals at a time). Poorer customers will invest the time in finding and using a deal.

They both get the same sandwich, but McD got them to pay different prices for it.

I think my normal approach to coding is "Scrappy" followed by "Surgeon" i.e. get the thing that works done in simple code style and then apply a series of transformation to obtain something that is significantly more complicated (and performant).

But maybe that's a peculiarity of the numerical algorithm performance space I live in, where debugging the numerics of a fully parallelized and vectorized algorithm with all sorts of performance bells and whistles, inline assembly and accelerator usage is much much more difficult than fixing the bug in simple scalar C code.

The scary thing for me is when they've got an 18 year old drone operator making shoot/no-shoot decision on the basis of some AI metadata analysis tool (phone A was near phone B, we shot phone B last week...).

You end up with "Computer says shoot" and so many cooks involved in the software chain that no one can feasibly be held accountable except maybe the chief of staff or the president.

That's not forgetting the ability for them to just straight up 100% legally purchase a lot of this information from data brokers.

The concern is they won't be 17 forever. 5/10/20/30 years down the line some small portion of these kids are going to hold important jobs, and some of them will have worthwhile blackmail material in their tiktok history.

Source? Many companies seem to be stopping offering insurance in the state just fine!

The most recent moves seem to be relaxing the pricing rules to allow major disaster pricing and recharging reinsurance rates in exchange for insurers offering more policies in high risk areas.

I did a PhD and about a decade in postdoc/early-career researcher posts before moving into tech. That was in Computational Mathematics, it was clear that the most successful people in the field were the ones who had found areas where they could publish "Technique X applied to field Y" type papers, so for each new X they could get 10 publications (by way of 10 different PhD students). These people generally could steer the core funding in the discipline their way.

Everyone else basically had to reformulate their research to pretend it was applicable to the government's funding subject de jure. This led to some quite large stretches in definition to achieve "<Main area of research>, and some applications in <funding stream>". This very much felt like it was sucking up to money.

I got out of the academia in the end because it felt like the more senior I got the more time I spent applying for funding and managing the spending and the less time I spent doing research/development. (Also given I was in a UK public sector institute, the pay was shit due to 40 years of below inflation pay rises crippling the institution).

Do we know if this was a bug in the beta releases of 15.2, or did it manifest only in the final version?

CPUs and GPUs are fundamentally aiming at different vertices of the performance polygon.

CPUs aim to minimize latency (how many cycles have to pass before you can use a result), and do so by way of high clock frequencies, caches and fancy micro architectural tricks. This is what you want in most general computation cases where you don't have other work to do whilst you wait.

GPUs instead just context switch to a different thread whilst waiting on a result. They hide their latency by making parallelism as cheap as possible. You can have many more cores running at a lower clock frequency and be more efficient as a result. But this only works if you have enough parallelism to keep everything busy whilst waiting for things to finish on other threads. As it happens that's pretty common in large matrix computations done in machine learning, so they're pretty popular there.

Will they converge? I don't think so - they're fundamentally different design points. But it may well be that they get integrated at a much closer level than current designs, pushing the heterogeneous/dark silicon/accelerator direction to an extreme.

That quickly becomes unfeasible for things that are not single input (and still requires being able to identify a correct result).

Unless the underlying code has been designed specifically for it (at the cost of some lost performance), it is a somewhat unreasonable expectation for high performance numerical code to always return the same result across version changes. Even running the same code on different machines, or the same machine with differently aligned data is likely to return different (but equally mathematically valid) results.

Sometimes its more about numerical stability than absolute accuracy (numerical stability being defined as not have the property that small changes in input cause large changes in the output).