Yuriy Stets @stainless_code

Normalize caring about the details

Why is it so fucking hard for self-proclaimed "experts" to understand that uploading your proofs, workings, source material and other sensitive data to someone else's cloud infrastructure means you don't own it anymore?

Jeffrey Shallit 🇺🇦 @shallit43

3 days ago

A new risk for mathematicians: a colleague reports that immediately after they posted an abstract of their upcoming talk online, a student elsewhere used AI to derive proofs of the stated results and then posted it on the arxiv. My colleague hadn't posted to arxiv yet.

83 216 3K 303K 456

If this is such a big differentiator for some use cases vs others, then ideally you would provide two flavors in the APIs, so that the user has the choice of which way of the trade off they want to make - with corresponding performance payment. I don't have a lot of xp with audio currently, but it seems to me that the planar format would a bit awkward to do, if you just want to play and mix audio clips. And the planar one you would want if you want to do some processing on the audio. Though having a big sample buffer is kind of pointless for real-time audio, so this whole discussion might be a bit of a moot, as the conversions would not cost a lot. The more important question here is API ergonomics and whether the API design decisions forces the user to do useless/redundant work, because for example, the source of audio might produce it interleaved, the API is planar and the underlying native APIs commonly require interleaved format, there are two useless conversions for no reason.

Vanilagy @vanilagy

2 days ago

There's this GitHub issue by Casey Muratori on how the Web Audio API has a design gap since it wants in planar format, and because many systems produce interleaved audio instead, converting between the two is costly and has "substantial performance penalties". I do not know why

39 2 240 81K 139

I always wondered why can't we have asymmetric CPUs, where you would have like a core to run your OS kernel and maybe a core to run drivers/IO/interrupts. And the rest of the cores strictly user-space, where an application would have some ability to allocate/pin cores from kernel. That would also make cores a lot simpler (not having priviledged instructions and other non-ring3 crap and other bloat), potentially even more performant and maybe with ability to do your own user-space scheduling over your allocated/pinned cores - want to do cooperative multithreading -sure, want to do lockstep wave of work over multiple cores - there you go. And the kernel cores would also be simpler - no FP, maybe only basic integer SIMD, and other things that the kernels don't really need.

@CaptainGPU Що мається на увазі? Тут мова йде про те що коли хтось користується хостнутими ЛЛМками, кимось ззовні організації, це автоматичне порушення НДА, бо куски коду відправляються на сторонній сервер.

I've heard the mantra "programmer time is more expensive that hardware" way too many times. Look at where they are now.

NOTimothyLottes @NOTimothyLottes

2 weeks ago

@valigo What does it say when software people claim their software sales are crashing because of hardware costs? As if one cannot make a good game on existing hardware ….

3 9 55 2K 1

Even on the cpu indices > pointers. The pointers waste a lot of cache space to store useless bits that do not carry much of a value. But I havent yet found a good/elegant solution of how to organize storage of multiple indices that belong to different contiguous chunks of memory. Because if all of your indices belong to a single space, then you can carry the single base pointer around OOB, and index only off of that pointer. But If you have multiple spaces, let's say one or more index spaces per thread (e.g. per-thread arenas or something), like what would be an efficient way to represent that. One way you can take some bits of an index to say which chunk you want to address into, but that eats into the size of indexable space and if you have a user-selectable number of threads - the number of bits reserved would be unpredictable.

NOTimothyLottes @NOTimothyLottes

2 weeks ago

Nothing changes the physical reality of the inefficiency of a vector of 64-bit pointers on the GPU. It will always take double the register file space, double the ALU ops to manipulate compared to using HW shifted 32-bit indexes.

4 7 60 11K 25

@SebAaltonen @justix_lol But the images have to be created with undefined layout and then transitioned to general layout right after per vulkan spec. Is it possible to avoid that somehow?

@SebAaltonen Is there a reason why we can't have constant/static samplers declarations in the shaders directly? There is literally an OpConstantSampler in spirv..

I sure am enjoying all this great new software we have due to 3 years of massively amplified productivity due to AI...!

@SebAaltonen I would call it either NoGL or MinGL.

@SanderSkjegstad @lea_fac There is something missing from Casey's voice though, I think maybe some lower frequencies. It sounds kinda like a very 70 year old man's voice, or am I tripping?

@damageboy @bmcnett Go up a level, the trillion dollar mistake was using malloc/free in the first place.

Uniform buffers suck in general. Making a lot of small buffers to store a single struct is a bit wasteful, as the API implementation now has to have a tracking data structure, probably even hash tables, god forbid. Pointers in shaders were supported since like mid-2010ish hardware. You can just allocate all of your "uniforms" from a single buffer, and only pass a single pointer to a shader, that way you can access those uniforms by offset, as long as the access is uniform.

I'm considering of adding ability to generate structs during compile time to my language. The idea seems fine to me in some cases. Yes, there is a complexity concern and careful control of the struct layout is more difficult, but for some things that are not crucial it is probably fine. But I'm having trouble coming up with some (even vague) examples of where this might be useful, so I'm still on a fence about it. The LSP/IDE should not have an issue with it, as the compile time code that generates the struct should already have been ran. You IDE should have an option to show an alternative view of the struct - show all of the generated members, as it already should have a struct layout visualizer, if it is worth anything. The compilation time shouldn't be a big problem in theory, but this is C++ and the implementations are so complex, that you can't really expect much here.

Stoke Willie @StokeWillie

2 months ago

People are worried about the syntax of reflection, but I’m afraid of something else. I expect reflection to be abused on a massive scale, to the point where no LSP will be able to find a type definition for you, and compile time will be comparable to a flight to the Andromeda

12 7 166 12K 37

At least I don't have to hear about how great pair programming is anymore

C++ has been tunred more and more into an abomination with every standard since C++11, it is became a joke. I don't even care to do research, but do they even support runtime reflection (introspection only, as you can't change the structs at runtime)?

♡ mari/cohe ♡ @noinconsistency

2 months ago

C++26 reflection syntax looks abhorrent

187 110 2K 860K 444

@SebAaltonen I can't seem to find any of the previous SIGGRAPH talks, only some strange bits and pieces. I assume they are not recording any and not interested in publishing any of them? kinda sucks..

Wanted to give the handmade/data-oriented style a shot, so rewrote the codebase in pure c, no c++ stl or c++ features. Over 1k lines gone, and look at the files! 87 files down to 13. identical functionality. The biggest win (and the reason I did this in the first place) is that compile times went from ~9seconds down to ~240ms. Ok, NOW i'm starting to understand the anti-oop folks, this is wild