Aren't shader programs more like ISPC (or OpenCL/CUDA), in that the programming model is based around 'pretend each SIMD lane is thread'?
645 karma · joined October 28, 2016
Similarly, in C, you can just give the definition of printf and omit the include of stdio.h, which also saves a ton of preprocessed lines.
When you say the compiler explorer can do it, do you mean that it will 'inline' the output in a similar way to the assembly i.e. you can view the results 'within' the source code?
Since it's source-to-source, I don't think being based on clang actually matters for anything unless you happen to use GCC-specific extensions. I would also expect clang and gcc to behave similary when cutting through abstraction.
I'm not sure, but it also seems like the output code should be able to compile? Then you can probably use g++ for that step.
Being able to cut through abstraction is very nice and quite important when you want to understand WHAT you are writing from the machine's perspective (or even in general when you don't know the abstraction yet). I love using Haskell, but have no idea what kind of machine code GHC spits out at the end (something based on the spineless tagless G-machine, an abstraction I barely understand by itself).
One could probably sneak a buffer overflow or use-after-free into a C project they maintain without being noticed. Actually shipping a trojan is much harder, as observed with the xz-to-sshd backdoor.
The attacker indeed laid dormant for two years, pretending to just be maintaining xz.
I really don't see any way how this wasn't malice on Jia's part. But I do think your hypothesis applies to Lasse, who was just happy someone could help him maintain xz.
Finding this out requires... meaningful performance analysis. That's right, this 1% perf hit will make it extremely easy to find the reasons for 5,10,20,50% slowdowns, and enable developers (and you!) to fix them.
By making it easier to profile software, YOU can notice performance issues in the software you're running and deliver a nice patch that will improve performance by more than was lost, making this 1% slowdown a very effective, high-interest investment.
Stuff like this is making me lean more towards getting an Intel for my next computer, at least on desktop where their worse power efficiency is less of an issue. But then they keep gating AVX-512 due to their E-cores not supporting it... You really can't win these days.
(It's actually the build-up to Radioactivity, but it's often listed as a separate track for some reason.)
So you'd probably need the "not available, but already 'stolen' case". For example, the current machine could look for work to steal itself. But this probably will increase latency a lot, so it would only make sense if the batches are huge.
What?? Plasma/KWin 5.27 already had support for VRR. On Gnome/Mutter, it's still in a merge request (or maybe it's finally been merged recently? not sure but it's definitely not in any released version to my knowledge).
Not sure about partial scanout, but Plasma 6 also enables basic HDR support (although it doesn't seem to work well on my Nvidia machine, SDR-on-HDR looks very washed out).
Gnome is indeed massively ahead in terms of extensions, but I don't know how much of that is due to capabilities vs. market share. See for example Karousel https://github.com/peterfajdiga/karousel.
From my perspective KDE is much farther ahead in pushing Wayland features. Apart from them currently shipping VRR and HDR, there is also for example long-standing support for XWayland-native scaling that Gnome is just now starting to consider. Or how about implementing server side decoration instead of forcing applications to use something like libdecor?
I don't think there's a very close relationship between GNOME and GIMP, but do keep in mind that GTK, the 'defining' part of GNOME, originated in GIMP (Gimp ToolKit!)
This is incorrect. You can minimize windows on Gnome, but the button to do it is hidden by default. It can be re-enabled in Gnome Tweaks, and there is also a keyboard shortcut (Super+H) for minimizing.
Gnome is however indeed fairly workspace-centric.
As for customization, out of the box Gnome is quite rigid, but its extension ecosystem far surpasses that of KDE. You can use extensions on Gnome to for example get a dock or system tray back.
The panel is around 50px or so at most, by default it seems to be 44px. And I indeed think the screenshot is scaled, since it looks like it's bigger than on my machine.
I checked out QtCurve on my laptop which still runs KDE 5 (it seems to not be ported to Qt6), and it is indeed a bit more compact than Breeze 5. It's definitely a bit more on the cramped side in my opinion though, as the toolbar buttons have barely any padding at all around them. I definitely don't think it's wasteful, at least.
I agree that the toolbar and search pane are a bit hungry for vertical space in Breeze, but I also don't think most Kate users have the search pane open regularly. Making it more suitable for the sidebar (a la VSCode) might be nice though, but it seems it already does some limited self-rearrangement when horizontally limited (which could look better, granted).
It can be seen that Breeze 6 does save a few pixels here and there at least, without looking cramped in any way.
As for disabling UI elements, I personally think the toolbar in Kate is fundamentally wasteful. The only way it might become useful is when you customize it to contain actions that you do tend to use regularly.
KDE: let's make our panel floating by default to distinguish ourselves visually from Windows! later Microsoft rumored to introduce floating panel in Windows 12.
No it's not 1080p tall? The image is 945 pixels tall, including an extensive box shadow. I'd wager that it's around 800 pixels high. The font also looks significantly bigger (esp taller) than it is on my machine.
Additionally, the search panel is usually not folded out. You can also move it to the side at your discretion (although I don't think the Kate search pane is very well suited to that). In Kate I also remove the toolbar so that I only have the menu bar, since new/open is rare for me (I use the file tree), save is just ctrl+s, and undo/redo is also something I use keyboard shortcuts for.
I don't use Kdenlive, but I don't see the problem for the clip problem list window either. Maybe the buttons on the side might be better located at the bottom, but that's it. The only real problem is that the window should probably be larger than it is on the screenshot, however it looks like you can freely resize it.
Finally, the things you mention are not related to the theme at all, but instead the layout of individual applications.
Did you actually look at the screenshots? KDE did not remove separation between elements. However it is now achieved by drawing a single line between two elements, instead of framing every single thing which is extremely ugly.
I also find Kate '6' to be much more pleasant to use, because this separator is still clear enough, but actually uses marginally fewer pixels which is nice on my low-resolution laptop.
I think the UI is way cleaner than e.g. the old JetBrains UI. The new JB UI is on the other hand pretty comparable to VSC.
Which editor that is doesn't really matter. VSCode is probably easiest, but Neovim, Kate, LiteXL, Lapce, Emacs, kakoune, helix, really pretty much all of them should work decently well.
I've had similar issues with VscodeVim being weird in VSC. Ultimately the text editor is so core to a text editor (duh) that deeply modifying it is bound to give a worse experience than implementing it from scratch, even if it does give you a lot of nice stuff 'for free'.
As such Fermi seems to be the shortest supported architecture, and it was around for 7 years. GCN4 (Polaris) was introduced in 2016, and seems to have been officially dropped around 2021, just 5 years in. While you could still get it working with various workarounds, I don't see the evidence of Nvidia being even remotely as hasty as AMD with removing support, even for early architectures like Tesla and Fermi.
Those prices in the French store look absolutely wild to me. In the Dutch store, the base model T14 Gen 4 AMD starts at 999, without any discounts visible!
As such, you're better off getting e.g. a 5700X or even some X3D chip, which are much faster. The 5000G processors are slower than their 5000X or 5000 counterparts, since they have less cache.
In fact, pretty much all of the performance gain going from a 5700 XT to a 6700 XT is based on the latter's higher clock speed, as their specs are very similar otherwise (although a 6700 XT has 12 GB 192bit memory and a heap of cache, whereas the 5700 XT has 8GB 256bit memory that runs a small bit slower, and crucially, way less cache).