audidude

Does it still completely screw up file/group owners in user containers? Because they keep saying it gets fixed and then that 1 out of 10 times it's not.

I found it hard to believe we couldn’t get a wakeup timer more granular than 1 ms, so I looked at what KWin was using. Indeed, it was passing the sleep duration in milliseconds to a QBasicTimer.

I fixed the same thing in GNOME a few years ago across GLib, GTK, and Mutter/GNOME Shell. It required getting glib onto ppoll() finally.

This feature (fibers in systemd) was also modeled after libdex (which I wrote for GNOME).

I've been doing this with something very similar in GNOME for years now. It also does io_uring, threadpool schedulers, workstealing, "pollable semaphores" (like IRIX), profiler integration, and makes fibers implemented as futures themselves.

https://github.com/GNOME/libdex/

The good news is that before writing Ptyxis, I also ported GNOME Terminal to GTK 4 and doubled the performance of VTE. So you know, use whatever you like.

Almost all of that is Mesa shaders and GTK's CPU side font-cache for GL/Vulkan, compiled CSS state, FWIW.

If you run:

GSK_RENDERER=cairo ptyxis -s

You can verify that with 69,985 here RES and 52,428 of that SHR. With 5 tabs open it jumped to 71,208 here. Presumably for the encrypted scrollback pre-allocations.

You still may not choose to use it, but it should stay relatively similar the more tabs you open.

Also, it's not a core GNOME app. It's just an app I wrote for me that the distros seem to have liked for its design/platform integration.

In most cases you're already using signalfd in places where libdex runs.

I'm not normally keen to "well actually" people with the C standard, but .. if you're writing in assembly, you're not writing in C.

These days on Linux/BSD/Solaris/macOS you can use makecontext()/swapcontext() from ucontext.h and it will turn out roughly the same performance on important architectures as what everyone used to do with custom assembly. And you already have fiber functions as part of the Windows API to trampoline.

I had to support a number of architectures in libdex for Debian. This is GNOME code of course, which isn't everyone's cup of C. (It also supports BSDs/Linux/macOS/Solaris/Windows).

* https://packages.debian.org/sid/libdex-1-1

* https://gitlab.gnome.org/GNOME/libdex

In X11 we kept things simple by offering:

* Core protocol drawing (lines, rectangles, arcs, the classics)

* XRender for compositing and alpha

* XShm for shared-memory blits

* GLX if you felt like bringing a GPU to a 2D fight

* XVideo for overlay video paths

* Pixmaps vs Windows, because why have one drawable when you can have two subtly different ones

* And of course, indirect rendering over the network if you enjoy latency as a design constraint

So the state of 2025 then tests a VTE that is from 2023? 4 major releases behind? And through a GTK 3 app, not even a GTK 4 one which will use the GPU?

Red Hat announced RISC-V yesterday with RHEL 10. So this seems rather expected.

https://www.redhat.com/en/blog/red-hat-partners-with-sifive-...

As someone who went down this path many years ago, I think the GTK numbers in the article are a bit misleading. You wouldn't create 1000 buttons to do a flamegraph properly in GTK.

In Sysprof, it uses a single widget for the flamegraph which means in less than 150 mb resident I can browse recordings in the GB size range. It really comes down to how much data gets symbolized at load time as the captures themselves are mmap'able. In nominal cases, Sysprof even calculates those and appends them after the capture phase stops so they can be mmap'd too.

That just leaves the augmented n-ary tree key'd by instruction pointer converted to string key, which naturally deduplicates/compresses.

The biggest chunk of memory consumed is GPU shaders.

https://pagure.io/fesco/issue/2817#comment-826636 will probably get you started into the relevant paths. Python 3.12 was going to include frame-pointers anyway for perf to boot. So they needed to fix this regardless.

This is a bit of a mischaracterization of the Python side of things.

They only opted out for 3.11 which did not yet have the perf-integration fixes anyway. 3.12 uses frame-pointers just fine.

I think your viewpoint is valid.

My experience is on performance tuning the other side you mention. Cross-application, cross-library, whole-system, daemons, etc. Basically, "the whole OS as it's shipped to users".

For my case, I need the whole system setup correctly before it even starts to be useful. For your case, you only need the specific library or application compiled correctly. The rest of the system is negligible and probably not even used. Who would optimize SIMD routines next to function calls anyway?

It's a disaster no doubt.

But, at least from the GNOME side of things, we've been complaining about it for roughly 15 years and kept getting push-back in the form of "we'll make something better".

Now that we have frame-pointers enabled in Fedora, Ubuntu, Arch, etc we're starting to see movement on realistic alternatives. So in many ways, I think the moral hazard was waiting until 2023 to enable them.

Absolutely. We've gotten numerous double digit performance improvements across applications, libraries, and system daemons because of frame-pointers in Fedora (and that's just from me).

I regularly have users run Sysprof and upload it to issues. It's immensely powerful to be able to see what is going on systems which are having issues. I'd argue it's one of the major reasons GNOME performance has gotten so much better in the recent-past.

You can't do that when step one is reinstall another distro and reproduce your problem.

Additionally, the overhead for performance related things that could fall into the 1% range (hint, it's not much) rarely are using the system libraries in such a way anyway that would cause this. They can compile that app with frame-pointers disabled. And for stuff where they do use system libraries (qsort, bsearch, strlen, etc) the frame pointer is negligible to the work being performed. You're margin of error is way larger than the theoretical overhead.

Shadow stacks are cool but aren't they limited to a fixed number of entries?

Current available hardware yes. But I think some of the future Intel stuff was going to allow for much larger depth.

Is the memory overhead of lookup tables for very large programs acceptable?

I don't think SFrame is as "dense" as DWARF as a format so you trade a bit of memory size for a much faster unwind experience. But you are definitely right that this adds memory pressure that could otherwise be ignored.

Especially if the anomalies are what they sound like, just account for them statistically. You get a PID for cost accounting in the perf_event frame anyway.

It does cause more memory pressure because the kernel will have to look at the user-space memory for decoding registers.

So yes it will be faster than alternatives to frame-pointers, but it still wont be as fast as frame pointers.

I added support to Sysprof this weekend for unwinding using libdwfl and DWARF/CFI/eh_frame/etc techniques that Serhei did in eu-stacktrace.

The overhead is about 10% of samples. But at least you can unwind on systems without frame-pointers. Personally I'll take the statistical anomalies of frame-pointers which still allow you to know what PID/TID are your cost center even if you don't get perfect unwinds. Everyone seems motivated towards SFrame going forward, which is good.

https://blogs.gnome.org/chergert/2024/11/03/profiling-w-o-fr...

These are two common things I ask new friends so that I can communicate better with them (aphantasia and inner monologue).

Nothing, I have aphantasia.

In the profile details

I am.

It's been on my radar for a long time and I have prototypes for one that are bitrotting on gitlab. There are three major design pieces of it.

First, It has an executable that runs in your development container (environment/etc) which means you can load libraries/typelibs/girs/etc just like the app would without crashing the IDE (or Glade in the old days).

Second, everything is an AST node so doing fun manipulations, unlimited undo, etc is just tree mutations.

Third the worker process does the rendering to a render node tree which is then shipped over to the Designer process to render.

The cambalache author and I are friends, so we occasionally talk about how we can make things work to integrate from Builder.

As for blueprint, that is outside of my knowledge area. I still do everything in XML and would prefer a designer to work with trees anyyway. Not sure I'd go the route of mutating a blueprint AST, but I hear it has back-and-fro to XML so that would probably be fine.

Also, if you want to make this a higher priority, lobby my employer (Red Hat) to make sure they know it's important to you.

Secondly, help me with _any_ of my other projects so I have some cycles to dedicate to it. People rarely notice but Builder, Sysprof, Text Editor, D-Spy, Manuals, Ptyxis, etc... are all one-man (split between many) projects and libraries.

Yes, that is right, Visual Studio for Mac is a closed source version of the formerly open source MonoDevelop IDE after Microsoft acquired Xamarin.

Having all of my GPL code ripped out of MonoDevelop so it could become Visual Studio for Mac was the straw that made me write GNOME Builder, GNOME's flagship IDE.

Surprisingly, still GTK 3 which means software rendering.

If they get it to GTK 4 and recent WebKit release they'll get a lot of DMA-BUF usage to bring many of those WebKit->GTK->Compositor copies to 1 (or in some offloading cases, zero).

It's extremely easy with GTK these days too because libpeas has a luajit backend (along with SpiderMonkey, Python, and of course anything native) and they all are backed by GObject Introspection to call into the C libraries/app.

You can't pipeline X11 operations in the presence of anything but a perfect network because

1. TCP streams require stalling when packets are dropped to keep the stream in order

2. X _requires_ by design that commands are performed in order

Which means that using something that can do UDP and manages it's own sequence ordering can do significantly better. This is why things like RDP, PCoIP, etc could do full frame rate HD video 15 years ago and you still can't with X protocol over the network.

Breaking up the screen into small 16x16 chunks or so, encoding on the GPU, and shipping that turns out to be significantly faster.

Especially when you take into account that virtually _nothing_ draws with X using X drawing primitives. It's almost all using Xshm for anything non-trivial.

Describe "just"?

How about input events? How about vsync synchronization? How about monitor information? How about clipboard? How about drag'n'drop?

GDK does an awful lot of lifting for Just here.