Conversation

Notices

1. Embed this notice
   Dmytro Oleksiuk (d_olex@mastodon.social)'s status on Monday, 24-Nov-2025 11:51:36 JST Dmytro Oleksiuk

   While environmentalists loosing their shit about carbon footprint of blockchains and LLM models — I have another question: has anyone tried to estimate comparative carbon footprint of JS/JVM/.NET JiT compilers? I mean, like, seriously — instead if shipping pre-compiled binary artifacts we forcing millions of clients with nearly identical hardware and software configuration to perform the same set of unnecessary heavy computations every time when someone visits random web page or opens random app

   • Embed this notice
     ✧✦Catherine✦✧ (whitequark@mastodon.social)'s status on Monday, 24-Nov-2025 11:51:25 JST ✧✦Catherine✦✧

     in reply to

     • Graham Sutherland / Polynomial
     • buherator

     @d_olex @gsuberland @buherator i couldn't disagree more; i find FPGA development (both RTL and toolchain) nearly trivial compared to UI/frontend

   • Embed this notice
     Dmytro Oleksiuk (d_olex@mastodon.social)'s status on Monday, 24-Nov-2025 11:51:26 JST Dmytro Oleksiuk

     in reply to

     • Graham Sutherland / Polynomial
     • buherator

     @gsuberland @buherator True, but in the same time modern UI/UX develooment is incomparably more simpler than low level code. I think we all lost our sane mind when started to assume that it’s somehow difficult to write mundane client-side stuff like Spotify or e-mail app

   • Embed this notice
     Graham Sutherland / Polynomial (gsuberland@chaos.social)'s status on Monday, 24-Nov-2025 11:51:27 JST Graham Sutherland / Polynomial

     in reply to

     • buherator

     @d_olex @buherator yup, but there's a different mindset there and different tradeoffs. I wouldn't want a kernel dev doing UI/UX development work; I've seen that software and it's horrrribbble lmao

   • Embed this notice
     Dmytro Oleksiuk (d_olex@mastodon.social)'s status on Monday, 24-Nov-2025 11:51:28 JST Dmytro Oleksiuk

     in reply to

     • Graham Sutherland / Polynomial
     • buherator

     @gsuberland @buherator So, it basically boils down to “we already have too many people who already been thought to use legacy inefficient tech that we already have” problem which is rather political/administrative than purely technical

   • Embed this notice
     Dmytro Oleksiuk (d_olex@mastodon.social)'s status on Monday, 24-Nov-2025 11:51:28 JST Dmytro Oleksiuk

     in reply to

     • Graham Sutherland / Polynomial
     • buherator

     @gsuberland @buherator Good couter-example — OS kernel and computer game developers are somehow capable of shipping of highly sophisticated and optimized native code to millions of customers without bothering about that

   • Embed this notice
     Dmytro Oleksiuk (d_olex@mastodon.social)'s status on Monday, 24-Nov-2025 11:51:29 JST Dmytro Oleksiuk

     in reply to

     • Graham Sutherland / Polynomial
     • buherator

     @gsuberland @buherator You don’t need JIT for that, I did exactly the same for for the regular C/C++ programs

   • Embed this notice
     Graham Sutherland / Polynomial (gsuberland@chaos.social)'s status on Monday, 24-Nov-2025 11:51:29 JST Graham Sutherland / Polynomial

     in reply to

     • buherator

     @d_olex @buherator I know, but the issue is that if your developers are working in a non-native language then translating the native crash data back into something that they can understand in their original code flow can be more difficult. it's not impossible, but it's less straightforward.

     (keep in mind that most devs aren't like us and don't RE the guts of stuff all the time lol)

   • Embed this notice
     Graham Sutherland / Polynomial (gsuberland@chaos.social)'s status on Monday, 24-Nov-2025 11:51:31 JST Graham Sutherland / Polynomial

     in reply to

     • buherator

     @d_olex @buherator native AoT binaries often don't have the same metadata available so the crash data isn't as easy to work with. you don't get quite as rich a picture of what was going on when the crash occurred.

   • Embed this notice
     Graham Sutherland / Polynomial (gsuberland@chaos.social)'s status on Monday, 24-Nov-2025 11:51:32 JST Graham Sutherland / Polynomial

     in reply to

     • buherator

     @d_olex @buherator software with big user counts (think along the lines of browsers or stuff like Steam or Spotify) often ships with a crash handler program that gets invoked when the program crashes, and sends a telemetry ping back to the vendor, like a private version of what WerFault does. the telemetry usually includes metadata about the fault to help with debugging, and there are backends with clever triage features like stacktrace grouping to help prioritise bugs that hit many people.

   • Embed this notice
     Dmytro Oleksiuk (d_olex@mastodon.social)'s status on Monday, 24-Nov-2025 11:51:33 JST Dmytro Oleksiuk

     in reply to

     • Graham Sutherland / Polynomial
     • buherator

     @gsuberland @buherator What is “crash telemetry” in this context? Never heard this term before

   • Embed this notice
     Graham Sutherland / Polynomial (gsuberland@chaos.social)'s status on Monday, 24-Nov-2025 11:51:34 JST Graham Sutherland / Polynomial

     in reply to

     • buherator

     @d_olex @buherator we do have that for many JITs, but there can be tradeoffs in things like crash telemetry. still, for cases where you don't care about crash telemetry, there's a strong case to be made for shipping native ahead-of-time JIT'd binaries (and multiarch where possible)

   • Embed this notice
     Dmytro Oleksiuk (d_olex@mastodon.social)'s status on Monday, 24-Nov-2025 11:51:35 JST Dmytro Oleksiuk

     in reply to

     • buherator

     @buherator JIT improves performance when the rival is sorce code interpreter or byte-code VM, I’m speaking about shipping already compiled code for target platform/architecture

   • Embed this notice
     buherator (buherator@infosec.place)'s status on Monday, 24-Nov-2025 11:51:36 JST buherator

     in reply to
     @d_olex Good question, but I'd argue that bytecode solves existing problems, while in case of LLM/blockchain I mostly don't see that. Also, isn't JIT specifically a thing to improve performance, meaning less resource consumption? A related observation is that many use-cases for LLMs can probably be solved much cheaper, today. E.g.: better IDE features; more QA for web search results; better education so people can write and understand an email.
   • Embed this notice
     Dmytro Oleksiuk (d_olex@mastodon.social)'s status on Monday, 24-Nov-2025 17:24:21 JST Dmytro Oleksiuk

     in reply to

     • Graham Sutherland / Polynomial
     • ✧✦Catherine✦✧
     • buherator

     @whitequark @gsuberland @buherator These are different types. Hardware has natural complexity because subject area itself is difficult, UI has artificially introduced complexity because of horrible frameworks/toolkits written by horrible people

   • Embed this notice
     Dmytro Oleksiuk (d_olex@mastodon.social)'s status on Monday, 24-Nov-2025 17:43:18 JST Dmytro Oleksiuk

     in reply to

     • Graham Sutherland / Polynomial
     • ✧✦Catherine✦✧
     • buherator

     @whitequark @gsuberland @buherator There also were good frameworks/toolkits written by good people, like Borland, that made UI development much or less trivial. Industry killed it because as developer you can't ask >$200k salary for being good at C++Builder

   • Embed this notice
     ✧✦Catherine✦✧ (whitequark@mastodon.social)'s status on Monday, 24-Nov-2025 17:43:18 JST ✧✦Catherine✦✧

     in reply to

     @d_olex @gsuberland @buherator I started with C++ Builder and it was neither trivial (ever made a VCL Component? holy shit) nor made for very good UIs (no DPI scaling, not responsive to system fonts, not especially accessible because Delphi quietly reinvented a lot of system stuff and then people using it added on top...)

     CLX was a disaster too

   • Embed this notice
     ✧✦Catherine✦✧ (whitequark@mastodon.social)'s status on Monday, 24-Nov-2025 17:44:45 JST ✧✦Catherine✦✧

     in reply to

     • Graham Sutherland / Polynomial
     • buherator

     @d_olex @gsuberland @buherator Embarcadero is still around, you can download and use C++ Builder, it apparently makes iOS apps nowadays (no idea how), the idea that it was killed by SV careerists is delirious

   • Embed this notice
     Dmytro Oleksiuk (d_olex@mastodon.social)'s status on Monday, 24-Nov-2025 17:47:09 JST Dmytro Oleksiuk

     in reply to

     • Graham Sutherland / Polynomial
     • ✧✦Catherine✦✧
     • buherator

     @whitequark @gsuberland @buherator Have to try, haven't used it for ages. To my memory it was better than Qt and GTK

   • Embed this notice
     ✧✦Catherine✦✧ (whitequark@mastodon.social)'s status on Monday, 24-Nov-2025 17:49:21 JST ✧✦Catherine✦✧

     in reply to

     • Graham Sutherland / Polynomial
     • buherator

     @d_olex @gsuberland @buherator I started with C++ Builder 1 and transitioned from C++ Builder 6 to Qt 3 (you bringing it up is very much a "I was there when it was written" moment, ha) and haven't looked back. Qt had/has Qt Designer which was a very similar RAD tool with a _much_ better layout engine, though these days you'd be using Qt Quick which is a fair bit different

     CLX was (I think I tried it out only once) a very bad port of VCL on top of Qt or something, I think?

   • Embed this notice
     ✧✦Catherine✦✧ (whitequark@mastodon.social)'s status on Monday, 24-Nov-2025 17:54:00 JST ✧✦Catherine✦✧

     in reply to

     • Graham Sutherland / Polynomial
     • buherator

     @d_olex @gsuberland @buherator separately from that, the complexity of hardware mostly lies in shit languages (Verilog wouldn't be considered a serious contender anywhere else) and shit toolchains (Vivado is the best of the pack for proprietary ones and that's saying something). the subject area is easier than comparable programming (i.e. anything highly parallel) because if A and B aren't connected A can't affect B, unlike in software. you're mostly fighting tools all day every day

   • Embed this notice
     ✧✦Catherine✦✧ (whitequark@mastodon.social)'s status on Monday, 24-Nov-2025 17:54:01 JST ✧✦Catherine✦✧

     in reply to

     • Graham Sutherland / Polynomial
     • buherator

     @d_olex @gsuberland @buherator I think I've used C++ Builder 7 maybe once or twice and haven't used it since because it or the applications it generated didn't really run on Linux (you can actually get it to work on wine these days), plus it wasn't open source, plus the build system and reusability was atrocious. try making a VCL component and giving it for someone to use. it involved COM registration. what a fucking nightmare, I'm so glad I will never have to do that again

   • Embed this notice
     Dmytro Oleksiuk (d_olex@mastodon.social)'s status on Monday, 24-Nov-2025 18:22:12 JST Dmytro Oleksiuk

     in reply to

     @whitequark @gsuberland @buherator I'd say that software complexity is more or less constant, while hardware complexity tends to increase when tings becoming too small or too fast: charge leak bit-flips, EM interference, signal integrity & RF black magic aren't fits well into simplistic "A can't affect B" view

   • Embed this notice
     Dmytro Oleksiuk (d_olex@mastodon.social)'s status on Monday, 24-Nov-2025 18:46:39 JST Dmytro Oleksiuk

     in reply to

     • Graham Sutherland / Polynomial
     • ✧✦Catherine✦✧
     • buherator

     @whitequark @gsuberland @buherator I abandoned it after I discovered other operating systems than Windows and therefore got need for something more portable. CLX passed me by and it seems for good, more wrappers -- more problems

   • Embed this notice
     Dmytro Oleksiuk (d_olex@mastodon.social)'s status on Tuesday, 25-Nov-2025 00:48:47 JST Dmytro Oleksiuk

     in reply to

     • Graham Sutherland / Polynomial
     • ✧✦Catherine✦✧
     • buherator

     @whitequark @gsuberland @buherator IDK, personally for me concurrent programming in low level languages, unlike synthesized logic whatever, looks like almost calm and effortless work activity. The only thing that makes brain clack is writing lock-free algorithms from scratch, probably. I mentioned epoll() because many people considering it much difficult to work with (in comparison with thread or process based parallelism) when it comes to networking and protocols related tasks

   • Embed this notice
     ✧✦Catherine✦✧ (whitequark@mastodon.social)'s status on Tuesday, 25-Nov-2025 00:48:48 JST ✧✦Catherine✦✧

     in reply to

     • Graham Sutherland / Polynomial
     • buherator

     @d_olex @gsuberland @buherator there are places where the RTL abstraction breaks down, sure, but so long as you're staying within what's supported (e.g. not running bitstreams you haven't synthesized and timed on the same device as yours) the RTL abstraction is so much easier to work with than the threads abstraction

     funny you bring up epoll(), since that's a way to serialize a parallel process instead of actually dealing with the complexity of parallelism

   • Embed this notice
     Dmytro Oleksiuk (d_olex@mastodon.social)'s status on Tuesday, 25-Nov-2025 01:57:13 JST Dmytro Oleksiuk

     in reply to

     • Graham Sutherland / Polynomial
     • ✧✦Catherine✦✧
     • buherator

     @whitequark @gsuberland @buherator “more like threads” under single core preemptive multitasking machine that happened to have shortest possible quantum time. Like extreme concurrent execution environment that you keeps in your mind while writing parallel code, assuming that your code can be interrupted (and will be interruped) after each instruction

   • Embed this notice
     Dmytro Oleksiuk (d_olex@mastodon.social)'s status on Tuesday, 25-Nov-2025 01:57:14 JST Dmytro Oleksiuk

     in reply to

     • Graham Sutherland / Polynomial
     • ✧✦Catherine✦✧
     • buherator

     @whitequark @gsuberland @buherator … but overall they are solving rather different problems: concurrent/parallel programming allows to make computational-heavy code fast, while asynchronous stuff addresses IO-heavy code issues to make it efficient

   • Embed this notice
     ✧✦Catherine✦✧ (whitequark@mastodon.social)'s status on Tuesday, 25-Nov-2025 01:57:14 JST ✧✦Catherine✦✧

     in reply to

     • Graham Sutherland / Polynomial
     • buherator

     @d_olex @gsuberland @buherator if you write enough RTL those start looking like the same problem for you (is a barrel processor "more like epoll" or "more like threads"?)

   • Embed this notice
     ✧✦Catherine✦✧ (whitequark@mastodon.social)'s status on Tuesday, 25-Nov-2025 02:22:53 JST ✧✦Catherine✦✧

     in reply to

     • Graham Sutherland / Polynomial
     • buherator

     @d_olex @gsuberland @buherator this is one way to see it, but to me, the CPU itself is a type of state machine I can add whenever I'd like to save some resources; using a barrel processor vs. multiple normal cores, then, is a similar kind of tradeoff in that to save your logic and/or complexity budget you handle requests (I/O, code) serially instead of in parallel

     imagine the barrel processor example running the "threads" in disjoint address spaces, and I think that becomes clearer

   • Embed this notice
     Dmytro Oleksiuk (d_olex@mastodon.social)'s status on Tuesday, 25-Nov-2025 02:22:54 JST Dmytro Oleksiuk

     in reply to

     • Graham Sutherland / Polynomial
     • ✧✦Catherine✦✧
     • buherator

     @whitequark @gsuberland @buherator I think I understand why you mentioned barrel processor in relation to epoll() specifically, but they are different things because in one case hardware will maintain program/thread/task state for you, while in other case you have to roll out your own state machine around asynchronous calls to accomplish this task