yvdriess

Over here in the real world of bottom 10% firing company cultures: those top engineers are leaving the company because they are tired of the culture of infighting and backstabbing, because setting up to others to fail and blaming them is just as effective as doing good work. Also, your super helpful generalist collaborator just got fired because everyone on your small team is highly performing and top down ruling was to fire 1/10 of each team.

I cannot think of a successful tech company that is still applying the GE 10% management style. It has consistently been shown to fail.

Control flow and data flow of programs are modelled as graphs so that certain analysis and transformations can be applied. That involves subgraph similarities, graph searches, graph transformation rules etc. And at the tail end, register allocation is graph coloring. Check out the LLVM and MLIR projects if you want some concrete modern examples.

Yep! I used BrookGPU for my GPGPU master thesis, before CUDA was a thing. AMD lacked followthrough on yhe software side as you said, but a big factor was also NV handing out GPUs to researchers.

somethingawful

That's true when you compare electrical vs optical links for NICs in datacenters. But this is about Silcon Photonics, which changes the equation significantly. e.g. it can be used for on-chip optical interconnects.

The silicon real estate being used for interconnect fabric PHIs is becoming significant and, unlike compute, do not scale well with node shrinks. On-die photonics means you can cut out a big chunk of your PHIs and avoid the the latency of going to NICs. The PIUMA architecture even used on-die switches to avoid having to use external switches.

https://www.tomshardware.com/news/intel-demoes-8-core-528-th...

Just before Epiphany, there was also the Tilera, which had a lot in common with the Transputer. Our lab got one and we played around with it, but it was a pain to program. Transputer had OCCAM, Tilera chased after the C model and shared coherent memory. The Tilera TILE architecture lives on in NVIDIA's DPU.

Saying this as a big hardware atomics enjoyer: Static atomic variables are not fast, are not parallel and definitely are the worst kind of cache misses.

Atomics are also atomic only on that one single operation, such as manipulating a single number in a struct or swapping out a pointer from one version of an object to another. To atomically expose a set of changes to a datastructure, you either use a lock or swap the old for the new, which is the driving example in the article.

Anecdotally, in my field, the actual interesting ideas are kept a company secret. The ideas that are not being deployed for competitive advantage are shoveled into salami-sliced patents to be deployed as ammunition in the big-corpo patent warfare battlefield. But here I am talking about a field where implementation trumps ideas. In some fields, e.g. pharma, most of the work and expense lies in finding a needle in a haystack. Once the product hits the market, the secret is out.

In both cases, I feel that the patent system fails its goal to make trade secrets public.

Very happy here too. The previous iteration (Family Sharing) locked you out of the entire library while someone was playing, now it's on a game granularity. The multiple copies part is also great. It was a hassle to set up an account and buy games for minor just to play certain coop games together. (Remote play together already works well for couch-coop games though)

No, the Cell is a many-core architecture with a Power 'general' core and 6-8 'special purpose' vector processing units.

Yes the government is subsidising the purchases of books when it puts a 5% VAT on it, where its substitutions are not. The state is financially supporting the product in order to incentivise its use. A tax incentive is an example of a subsidy.

Lowering or removing tax is subsidy for all intents and purpose. It functions in the same way.

> Now if you wanted to couple a VLIW design with a dynamically re-executing compiler (dynamic binary translation), then sure, that can be made to work.

RIP Transmeta

Famously, companions throwing themselves at you immediately was a bug they patched early on.

Both. Cheaper CPU-based inference, GPUs are not as competitive for sparse linear algebra. This could lead to much larger models, as you only touch a small portion of the matrix during inference. However, the training here is still dense-LA on a GPU, so you still blow up the compute cost when increasing model size.

> You could’ve stopped at 1. US auto manufacturers don’t know how to make anything but trucks. Not that they actually know how to make them, because they’re all pieces of shit, but just that’s the only thing people in the US buy from US manufacturers because no one else makes full size diesel pickups. Not the Japanese, the Koreans or the Europeans.

That's because of protectionist laws, aka the chicken tax: https://en.wikipedia.org/wiki/Chicken_tax Asian/European manufacturers were squeezed out of the light truck market. US manufacturers then had this lucrative niche they marketed the hell out of.

Germans are more accepting of nudity than most other countries, there are very few laws against it. Partly it's a legacy of the FKK (https://en.wikipedia.org/wiki/Freik%C3%B6rperkultur).

Worse, it's an ad delivery platform.

FYI Cray developed an interesting allocator for scaling to a massive amount of threads https://dl.acm.org/doi/10.1145/1122971.1122999

> You don't want something like that in a city centre.

Nuclear sites also have the tendency to be built on a nation's border.

Sure, but they are still going for the (French) homegrown AArch64 solution instead of the Fujitsu design.

It's definitely part of the linux kernel coding style: https://www.kernel.org/doc/html/v4.10/process/coding-style.h...

That's high end Xeon for you. At least here you can argue it can save you from buying a GPU.

What do you mean with accuracy here? Usually 50% accuracy means cointoss, meaning 20% accuracy is equal to 80% accuracy, which is better than the article's 78% and not that far from 90%.

The problem with that explanation is that in the past, there were a lot more women in computing. First as operators and programmer/mathematicians, later the gender mix was following the same upward trend as other sciences.

I've seen two explanations for the dearth of women in computing: engineering culture becoming dominant in the '60s (where it was more the domain of mathematics before) and the rise of personal computers that were advertised and marketed to young boys in the '80s. The latter is very noticeable in CS enrollment numbers.

Source, GameBryo, LithTech, ...

Correct.

This is also why hyperthreading yields a benefit for sparse/graph workloads. I was getting good results on the KNL Xeon Phi with its four hyperthreads. But you easily hit the 'outstanding loads' limit if your hyperthreads all do gather instructions every 4-8 instructions. The architecture needs to balanced around it.

Your regular DRAM memory controller will use the 64B bus to pull in a single 64B line of memory. In your modern x86 systems, that's equal to a cache line.

If you are only accessing a single 4B or 8B element of that cache line >80% of the time, as shown on the slides, you are wasting 7/8th of all memory bandwidth with irrelevant data. If you were to use that 64B memory bus to access 8x different 8B memory locations, you get a large boost to your effective bandwidth.

Those nodes in the queue have to come from somewhere and that is where the inefficiency lies.

If you use SIMD gather instructions to fetch all the children of a node, that is still going to be very inefficient on e.g. a Xeon. Each of those gather loads are likely to hit different cache lines, which are accessed only once and waste 7/8th of the memory bandwidth pulling them in. SIMD is also not going to help if you are memory bandwidth or latency bound, we're talking ~0.1 ops/byte here.

In some aspects, yes. Arguably, it's much harder to max GPUs because they have the added difficulty of scheduling and executing by blocks of threads. If not all N threads in a block have their input data ready or are branching differently, you are idling some execution units.