yvdriess

What do you mean with necessary context?

Modern compilers all autovectorize really well. Usually writing plain canonical loops with plain C arrays is a good way to write portable optimal SIMD code. The usual workflow I use is to translate the vector notation (RIP Cilk+ array syntax) in my paper notes to plain C loops. The compiler's optimization report (-qopt-report for icx, gcc has -fopt-info-vec and -fopt-info-vec-missed) gives feedback on what optimizations it considered and why it did not apply them. In more complex scenarios it can be helpful to add `#pragma omp simd` pragmas or similar to overrule the C semantics.

It's not the same, but boy it sure does rhyme.

Typical prose in late 90's early 00s: Designing the right UML meta-schema and UML diagram will generate a bug-free source code of the program, enabling even non-programmers to create applications and business logic. Programs can check the UML diagram beforehand for logic errors, prove security and more.

Can you still call it a spring cleaning when you take out support walls in the process?

There's no single good way, but yes as you said, logical deduction based on the surrounding instructions and their hardware counters is a way to do it. Instruction B might be collecting a ton of hardware counted cycles, but it could be because instruction A it depends on is slow. Sometimes, those dependencies are even implicit, since x86 is in-order commit some instructions like lock/atomics have implicit and dynamic dependencies based on what is in the reorder buffer at the time.

To give a concrete example I encountered analysing a GC: traversing the object graph in a loop means calculating the address of an object, loading that object, doing some work on it and then grabbing the bits to calculate the children to visit next. This creates a long brittle chain of data-dependent conditionals, depending on a calculation that eventually came from a much earlier load. That conditional branch might be 30/70 taken/untaken, so the branch predictor often does not speculate, reducing the ILP and making it harder to hide the load's latencies. Now, dear Watson, would you say the blame is to the front end? There are no stalls when all the loads go to fast cache, only when there is the occasional remote LLC hit, DRAM hit or god forbid cross-NUMA hit. What if I tell you that there's an atomic operation to mark the object as visited, which is fast in itself but can only be issued when all prior loads have completed and stops from newer instructions to be issued while it hasn't been committed.

You need to look at a whole bunch of surrounding instructions and a variety of hardware counters to start forming a picture. Insert Always Sunny in Philadelphia meme with the red wire crime board here.

Take front end bound with a grain of salt. Frequently I find a backend backpressure reason for it, e.g. long-tail memory loads needed for a conditional branch or atomic. There are limitations to sampling methods and top down analysis, consider it a start point to understanding the potential bottlenecks, not the final word.

For the readers that might miss it: that the last sentence was sarcastic: https://www.reuters.com/graphics/GLOBAL-ENVIRONMENT/INSECT-A...

In defense of the OP: bump allocators are part of the CPython runtime. It's used to avoid calling malloc a bazillion times a second. Of course, it still needs to defer to libc for certain objects and to grab more memory for its pools/arena/nursery.

Thanks for that article by the way. I've referenced it often to make the point that allocation behaviour is complex and messy.

> I don’t believe this in even the slightest. That is not a meaningful metric for literally any actual workload in the universe. It defies common sense.

I just want to make the point here that making bump allocators fast is useful because it's an essential part of modern allocators and will be called A LOT in case of CPython.

That benchmark is useful to make sure the codegen/JIT is performing like it should, but it is still just measuring bump pointer allocation in the most ideal situation. 2 cycles/alloc is entirely normal reasonable considering modern uarchs, the critical path is two one-cycle uops.

Now, I agree with your point that this is far from meaningful for the p95/p99 of actual workloads. That is indeed the metric that users or customers actually care about. Modern GCs, like Go's, have moved away from using throughput as a metric. It's "easy" to make bump allocators fast, the hard problem is everything else around it: you still need to allocate your arenas/pools and manage the object lifetime. In the case of CPython that's refcounting, deallocs, GCs, work that modern CPUs really suck at (bad locality, bad branching).

I measured ~19.5% of the wallclock time of pyperformance benchmarks being related to memory management (ISPASS25 poster). That's not taking into account the extra boxing and struct slots being created for bookkeeping purposes, which adds more second-order effect related to cache pressure. It's insanely hard to accurately measure memory management overheads.

Their pictoral representation is a "shut up and calculate" notation, you can always map it 1:1 with the linear algebra formulation. It was developed as a better tool of thought for working out proofs in QC.

I had the pleasure of interacting with Duncan and Bob when XZ calculus was being developed. While I did not use their calculus for my own research, it did inspire the graphical notation I doodled with.

While I agree that naming a thing after a person makes it less clear at first glance, it is definitely not to intentionally sound smarter and exclusive; it's simply a handy short label for often subtle and complex things in an environment where you are constantly referring to it. New fields or domains will typically develop their own notation, as they often require new tools of thought. I'm sure you are not suggesting that Feynman diagrams or Einstein summations making things more complicated than they really are.

To your point: the annoying part is when the conventions clash. In early QC works an X could be the X-gate or something else completely. A good chunk of the effort in writing or understanding a QC publication was establishing the notation. After a while notation gets a bit more consolidated as conventions get naturally established. Of course, if you move from a world that has established its own conventions, e.g. behind the iron curtain, it can be frustrating to be confronted with the many eponyms in a field where you already have deep expertise. I had similar experiences just from working in teams that were using different programming languages: "Why call it a SAX parser? That's just tree-recursive descent!"

Yes but those transistors moved to greener pastures.

It is interesting to contrast Notch's arc with Zach Barth's, if you are familiar with the Infiniminer[1] connection. The latter has continued to make small idiosyncratic games with a small team and following his own interests.

[1] https://minecraft.fandom.com/wiki/Infiniminer

Agreed, Intel needs to win back customers. Removing the MBA-staple strategy of artificial market segmentation would be a strong signal that they are serious about becoming an actual customer-first company.

Some counter points.

On the die size argument, which I see being echoed a lot online:

Why would a customer care or factor that into their purchasing decisions? Saying that these dGPUs with large dies are what is going to put Intel out of business is ludicrous and the Xe cores are shared amongst many of Intel's most lucrative products.

You can afford larger dies on N4 compared to when the 40-series were launched. It's no longer the leading edge node and yields have likely improved.

dGPUs have pretty expensive GDDR modules, I do not have data on the exact proportion but I would bet that the memory modules is the more important line item.

BoM matters less on lower volume (compared to mobile SoCs) dGPU units. Masks masks, R&D and validation are big fixed up-front costs.

Recurring software support is also independent of how many units get sold. Xe cores are shared by many Intel products (client & server CPUs, datacenter GPUs and gaming GPUs).

B580 is widely popular for gamers, Intel cannot keep up the demand at the moment. I doubt they need to unlock SRIOV on the gaming segment dGPUs to get rid of stock, as you seem to suggest. Their datacenter GPUs [1] offer support for SRIOV, as you probably already know, so I assume you are bemoaning market segmentation.

[1] https://www.youtube.com/watch?v=tLK_i-TQ3kQ -- Wendell's video on Flex 170 GPU from Intel - Subscription Free GPU Accelerated VDI on Proxmox 8.1

True, but it depends on what you mean with fitting in memory.

Succinct datastructures are used in genomics (e.g. bwa, megahit exome sequencer) because N is so large that you're actually hitting asymptotic behavior.

For memory latency it can by making your memory footprint fit in LLC or a single node; cross-node NUMA latencies are typically enough to absolutely tank performance.

It can theoretically also help in massively parallel access situations where bandwidth becomes a limiting concern. Although, I intuit we would need near-memory hardware to perform the rank+select. Otherwise the latency of the multiple dependent accesses will kill your performance again, cfr previous point.

With a lot of parallel accesses, bandwidth could also be an issue in conventional structures.

That's because the OP is linking to the quickstart guide. There are benchmark numbers on the github's root page, but it does not appear to include the new deepseek yet:

https://github.com/intel/ipex-llm/tree/main?tab=readme-ov-fi...

Can confirm. I experienced EU EC research project red tape to similar than DARPA.

Most of the red tape comes from excesses or abuses from the past. Government agencies tend to slap an extra layer of rules every time the grant money is being misused.

Those kind of rules also reveal what is being interpreted as misuse or abuse. For instance, you cannot expense a meal that includes an alcoholic beverage on an US federal budget.

If you love the sound of the Floppotron, chiptunes and metal, I can heartily recommend Master Boot Record. https://masterbootrecord.bandcamp.com/album/hardwarez https://soundcloud.com/masterbootrecordmusic/doom

Any concurrent GC will have an unpredictable impact on application threads. The more obvious is the necessary synchronization on GC startup and shutdown, e.g. to turn on write barriers during GC. Less obvious but perhaps more impactful is the cache trashing incurred by the GC threads' heap traveral.

Go GC's stop the world pauses are essentially synchronization barriers at the start and end of a GC phase. That pause length is a function of the number of worker threads, not the size of the heap. You can check this yourself by running the tile38 and cockroachdb benchmarks with GODEBUG=gctrace=1 .

Yep, it's an area denial weapon.

You basically cannot do anything worthwhile in this space without violating someone's patents. It's beneficial patent and corporate lawyers, but it's detrimental to innovation. As an engineer you are asked to not look up existing techniques or designs as this will taint you legally.

I agree that fuel cost and tax are not the reason trucks are so popular in the US. The main incentive for US manufacturers to have a large demand for light trucks because of the chicken tax. https://en.wikipedia.org/wiki/Chicken_tax

PCIe 4.0 16x

https://www.intel.com/content/www/us/en/products/sku/227961/...

For the consumer GPUs, PCIe 4.0 x16 has plenty of BW headroom. The full sized x16 is more for stability reasons. Some vendors even put a couple of M.2 slots on PCI4/5 GPU board to recuperate the unused PCIe lanes.

It's not the size of the technical insight that matters, it's what you know what do with it. Point being, a smart and capable CEO can still have misaligned incentives (read: optimize for personal benefit).

In defense of the chip designers:

Design pipelines are deep and Intel at the time famously had very node-specific designs without industry-standard PDKs. The moment engineers were told to switch a design to 14nm, it basically reset the 5 year design-to-product pipeline. Management failed because they did not hedge the risk by starting a parallel 14nm design effort at first sign of 10nm troubles. They likely were engaged in magical thinking or some variation of the "Are YOU going to tell him?" Silicon Valley scene. It does not help that information like that is considered actionable insider trading information. I bet a lot of people working on 10nm designs first heard the news about the delays from the quarterly investor calls.

It does help to retain the talent, those 5-10y engineers have a house on mortgage and need a higher pay incentive to uproot their lives. At least, that was probably the reasoning before, things have changed:

- WFH means you do not even have to move.

- Competitors have set up satellite offices in Hillsborough/Portland to poach talent.

- Intel does not feel like the stable employer anymore, with the almost yearly layoff waves since the BK era.

In short, timing-attack computed?

To add to that, AMD's has the more lucrative higher-margin part of that market.

Even without the patents, there is a lot in x86 and it would take an order of magnitude more engineers to make a compatible x86 CPU than a RISCV with standard extensions.