mandarax8

Because in your benchmark all std::map nodes were allocated in succession, most likely being placed in adjacent memory locations...

This likely won't be true in a real application with a non-trivial allocation pattern.

> I actually don't understand the tearing they're talking about. If the fields are final then you can't modify the Value Type anyway?

You can assign the object again to overwrite it 'in place'.

> And a simple write-lock bit for fat Value Types would solve everything while maintaining most of the performance benefits (both on read and write)

They even already have an extra 'null' bit tacked on to the value object.

Is there any reason that you couldn't implement this on Xorg?

Please read up some more about Java and GCs. Memory allocation and GC are heavily intertwined.

See https://fgiesen.wordpress.com/2012/07/21/the-magic-ring-buff... which takes it even further :)

Indeed I misread. I figured the NMI must have been nested or otherwise they wouldn't have gone through all this trouble just to drop samples :)

Not OP: how would you handle the second interrupt during the interrupt handler here then? I can see how you could use two separate ring buffers for different contexts, but I don't see how to handle the nested interrupt. Also indeed they just drop all these samples that get deadlocked.

Actually, as long as you use different ring buffers for interrupt/non-interrupt context, it should be fine to just drop if you encounter a deadlock due to interrupting an already running interrupt handler.

One thing wasn't clear for me in the article: is there only one such ringbuffer defined by the kernel or can the eBPF program specify as many ringbuffers as it wants?

I give up, tell me the AABB trick please

The entire point of the article is that you cannot throw from a destructor. Now how do you signal that closing/writing the file in the destructor failed?

Maybe we can even find some correlation in the bit pattern of the input and the Boolean table!

The pixel position has to be known, how else are you rasterizing something?

Their current OpenGL 4.1 actually does run on top of metal making it even more blatantly obvious that they just don't want to.

I'm not sure exactly what you mean, but you can both output line primitives directly from the mesh shader or output mitered/capped extruded lines via triangles.

As far as other platforms, there's VK_EXT_line_rasterization which is a port of opengl line drawing functionality to vulkan.

That said MSVC,GCC and clang all implement it to allocate an exact value.

Can you point me to some good middleware then? I haven't been able to find any.

Any kind of relative/offset pointers require negative pointer arithmetic. https://www.gingerbill.org/article/2020/05/17/relative-point...

You can still statically link all your own code but dynamically link libc/other system dependencies.

Yeah it's a shame that to go from your idea to something that's 'general' (ie just some arbitrary arguments) you need to write this arcane garbage.

std::bind is bad for him for the same reasons std::function is bad though

What he shows here is 75% of c++26's std::function_ref. It's mainly missing variadic arguments and doesn't support all types of function objects.

https://github.com/TartanLlama/function_ref/blob/master/incl...

But you can embed this 1 byte lock into other bigger objects (eg. high bytes of a pointer).

With 4 byte locks your run into the exact same false sharing issues.

Because the only way to do metaprogramming in C++ is via the type system. Thismakes it so you need to implement 'functions' as types.

Guess: it's too much water to cool down in a small local reservoir.

I would allow it, given they physically write down all N square root on a piece of paper.

'So what are the requirements for this project?'

'Requirements? Were agile, we'll figure it out as we go!'

...

Actual conversation a while back at work regarding a (now failed) project.

You're saying this as if psychedelics cannot 'have all sorts of severe, life-altering, mostly permanent side effects'.

I've never had hotspot not be fast enough. Even on 20Gb traces, everything is instant.

Only thing that ever takes some time is the initial load of the perf file and filtering (bit still really fast).

But this doesnt have the property that the product of the distances to the focal points is constant no?

Heres two examples for 3 and 6 points in 2D, 3D respectively: https://en.wikipedia.org/wiki/Cassini_oval#Generalizations

These are symmetric as well though.