Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I Always End Up Going Back to C

deplet.ing

Post reply on HN
Print view View original

51–60 of 76 posts

Re: Why I Always End Up Going Back to C

#51

Post by theamk »

wasmperson wrote: post #45
theamk wrote: post #28

Earlier quoted context omitted.

Good luck making any sort of UI without OOP-like methods. The moment you have grouped state (say "button_enabled", "button_shown", and "button_checked") and corresponding methods, you get something OOP-like. The only way to work around is immediate mode UI, but this requires fairly powerful CPU, so it's only feasible on the modern machines. Certainly not something that people would want about 30 years ago, they still…

Immediate mode UI doesn't require a powerful CPU and was invented in 2002, so about 24 years ago. I think the belief that it necessarily sacrifices performance is somewhat of a misconception. Compare a hypothetical "Immediate Mode" counter: void render_and_handle_button_click(struct ctx *ctx){ draw_text(ctx, "Count: %d", ctx->count); if(draw_button(ctx, "Increment")){ ctx->count++; } } To the equivalent "Retained" co…

You are looking at it from the user side, while all the interesting parts are on the implementation side:

- If you have partial redraw request, can you quickly locate _only_ the controls which are covered and only redraw those?

- If you are clicking on something, can you quickly locate which component will receive the click?

- If you are moving mouse, or dragging a selection, can you quickly determine if any components should change the state? Can you avoid running the full event loop on every mouse move event?

- If your application state has updated, do you need to force redraw or not? (Many immediate mode UIs fail badly here, never going to idle even if nothing is happening)

This is all trivial in the old-style UI - efficient redraw / mouse mapping is table stakes in the older GUIs. While all that immediate mode can do is to keep running redraw loop _every_ _single_ _time_ something as trivial as mouse move is happening, just in case this can change highlighted item or something.

(Unless the "immediate mode UI" is just a thin veneer, and library is using good-old OOP based GUI components under the hood... but in this case, it's still faster to cut out the middleman and control components yourself)

And yes, back when I was doing "game development" class in college, around that time, I've used the immediate mode UI for menus. This only makes sense - games run on foreground _anyway_, and they basically consume 100% of CPU anyway. But for regular apps? Please don't.

Example: I just opened https://www.egui.rs/#demo in background tab... The browser's task manager shows this tab never goes idle, consuming between 0.1% and 3%. Considering I often have 40+ tabs open, this can take a significant part of CPU.

Immediate mode GUIs, unless in app which already uses 100% CPU, like game or video player, will always be less efficient than classical event-driven ones.

Re: Why I Always End Up Going Back to C

#52

Post by rramadass »

pjmlp wrote: post #36
rramadass wrote: post #30

Earlier quoted context omitted.

Linux has libnuma ( https://man7.org/linux/man-pages/man3/numa.3.html ) while Windows has its own NUMA api ( https://learn.microsoft.com/en-us/windows/win32/procthread/n... ) For CPU/OS scheduling, use pthreads/OpenMP apis to set processor affinity for threads. For SIMD, use compiler intrinsics.

Nothing of that is written in pure C, as per ISO C standard. Rather they rely on a mix of C compiler language extensions, inline or external Assembly written helpers functions, which any language compiled language also has available, when going out of the standard goes.

That is not an argument. ANSI/ISO C standardizes hardware-independent parts of the language but at some point you have to meet the hardware. The concept of a "implementation platform" (i.e. cpu arch + OS + ABI) is well known for all language runtimes.

All apps using the above-mentioned are written in standard ANSI/ISO C. The implementation themselves are "system level" code and hence have Language/HW/OS specific extensions which is standard practice when interfacing with low-level code.

> any language compiled language also has available

In theory yes, but in practice never to the ease nor flexibility with which you can use C for the job. This is what people mean when they say "C is close to the metal" or "C is a high-level assembly language".

Re: Why I Always End Up Going Back to C

#53

Post by wasmperson »

theamk wrote: post #51
wasmperson wrote: post #45

Earlier quoted context omitted.

Immediate mode UI doesn't require a powerful CPU and was invented in 2002, so about 24 years ago. I think the belief that it necessarily sacrifices performance is somewhat of a misconception. Compare a hypothetical "Immediate Mode" counter: void render_and_handle_button_click(struct ctx *ctx){ draw_text(ctx, "Count: %d", ctx->count); if(draw_button(ctx, "Increment")){ ctx->count++; } } To the equivalent "Retained" co…

You are looking at it from the user side, while all the interesting parts are on the implementation side: - If you have partial redraw request, can you quickly locate _only_ the controls which are covered and only redraw those? - If you are clicking on something, can you quickly locate which component will receive the click? - If you are moving mouse, or dragging a selection, can you quickly determine if any componen…

You appear to be making assumptions about immediate mode UI limitations based on some implementations you've worked with and not based on what's actually dictated by the interface itself. You touch on this somewhat by claiming that it's possible to be fast as long as the UI is merely a "thin veneer" over something more stateful, but that isn't a distinction I care about.

I'm not a good advocate for IMGUI; there are resources available online which explain it better than I can. I'm just trying to point out that the claim that immediate mode GUIs are some sort of CPU hog isn't really true. That's what I meant by "doesn't necessarily sacrifice performance," not that there is literally zero overhead (although I wouldn't be surprised if that were the case!).

> ...The browser's task manager shows this tab never goes idle...

As far as I can tell, the demo you linked appears to be bugged. You can see from poking around in a profiler (and from the frame timer under the "backend" popout) that the UI code does in fact go idle, but the requestAnimationFrame loop is never disabled for some reason. Regardless, even if this particular GUI library has problems going idle, that's not an inherent problem with the paradigm. I get the impression you understand this already, so I'm not sure why you've brought it up.

Re: Why I Always End Up Going Back to C

#54

Post by rramadass »

pjmlp wrote: post #13
ivanjermakov wrote: post #10

> In C, you can see what the machine is doing. Allocations don’t hide behind constructors, and destructors don’t quietly run during stack unwinding. You can profile at the machine-code level without feeling like you’re peeling an onion, appropriately shedding tears the whole time. This is why explicit control flow is important design goal for systems programming language. This is basically 2/3 of core design principl…

Like setjmp()/longjmp() and signal(), very explicit. /s

The control flow is explicit; there is no language "magic" here. Non-local gotos in the former case and asynchronous callbacks from the OS in the latter case are pretty well known.

Re: Why I Always End Up Going Back to C

#55

Post by theamk »

flohofwoe wrote: post #48
theamk wrote: post #43

Earlier quoted context omitted.

I don't see how this can work. You have your personal string library.. and you move to a new project, and it has it's own string library (it's pretty much given, because stdlib C library sucks). So what next? Do you rewrite the entire project into _your_ string library, and enjoy familiar environment, until the next "experienced C programmer" comes along? Or do you give up on your own string library and start learnin…

It's not the "string library" that's important, but standardized interface types - so that different libraries can pass strings to each other while still being able to select the best string library that matches the project's requirements. In C this standardized string interface type happens to the poiinter to a zero-terminated bag of bytes, not exactly perfect in hindsight, but as long as everybody agrees to that st…

Are you saying that if you join existing project which uses acuozzo_strzcpy, and you need to do some string copying, instead of using the same functions that everyone already uses, you'll bring your own library and start using flohofwoe_strjcpy in all code _you_ write? (Assuming both of those work on char* types, that is)?

This.. does not seem like a very good idea if you want your contributions to be received well.

Re: Why I Always End Up Going Back to C

#56

Post by kvemkon »

theamk wrote: post #51
wasmperson wrote: post #45

Earlier quoted context omitted.

Immediate mode UI doesn't require a powerful CPU and was invented in 2002, so about 24 years ago. I think the belief that it necessarily sacrifices performance is somewhat of a misconception. Compare a hypothetical "Immediate Mode" counter: void render_and_handle_button_click(struct ctx *ctx){ draw_text(ctx, "Count: %d", ctx->count); if(draw_button(ctx, "Increment")){ ctx->count++; } } To the equivalent "Retained" co…

You are looking at it from the user side, while all the interesting parts are on the implementation side: - If you have partial redraw request, can you quickly locate _only_ the controls which are covered and only redraw those? - If you are clicking on something, can you quickly locate which component will receive the click? - If you are moving mouse, or dragging a selection, can you quickly determine if any componen…

> Many immediate mode UIs fail badly here, never going to idle even if nothing is happening

ImGui's author deliberately doesn't fix this because this is one of the main issues preventing ImGui to be widely adopted on desktop potentially attracting too many users at once but lacking support for all of them.

https://github.com/ocornut/imgui/issues/7892#issuecomment-22...

Re: Why I Always End Up Going Back to C

#57

Post by pjmlp »

theamk wrote: post #44
pjmlp wrote: post #36

Earlier quoted context omitted.

Nothing of that is written in pure C, as per ISO C standard. Rather they rely on a mix of C compiler language extensions, inline or external Assembly written helpers functions, which any language compiled language also has available, when going out of the standard goes.

I think you are being nitpicky here. When most people say "I write in C", they don't mean abstract ISO C standard, with the possibility of CHAR_BIT=9. They mean "C for my machine" - so C with compiler extensions, assumptions about memory model, and yes, occasional inline assembly.

I am, because people making C something special that it isn't.

Other languages share the same features.

Re: Why I Always End Up Going Back to C

#58

Post by pjmlp »

rramadass wrote: post #52
pjmlp wrote: post #36

Earlier quoted context omitted.

Nothing of that is written in pure C, as per ISO C standard. Rather they rely on a mix of C compiler language extensions, inline or external Assembly written helpers functions, which any language compiled language also has available, when going out of the standard goes.

That is not an argument. ANSI/ISO C standardizes hardware-independent parts of the language but at some point you have to meet the hardware. The concept of a "implementation platform" (i.e. cpu arch + OS + ABI) is well known for all language runtimes. All apps using the above-mentioned are written in standard ANSI/ISO C. The implementation themselves are "system level" code and hence have Language/HW/OS specific exte…

It is, because C is nothing special, those features are available in other languages.

Proven before C was even a dream at AT&T, and by all other OS vendors outside Bell Labs using other systems languages.

Then people get to argue C can X, yeah provided it is the Compiler XYZ C dialect.

Re: Why I Always End Up Going Back to C

#59

Post by pjmlp »

rramadass wrote: post #54
pjmlp wrote: post #13

Earlier quoted context omitted.

Like setjmp()/longjmp() and signal(), very explicit. /s

The control flow is explicit; there is no language "magic" here. Non-local gotos in the former case and asynchronous callbacks from the OS in the latter case are pretty well known.

Except knowing where the jump lands, very explicit.

Re: Why I Always End Up Going Back to C

#60

Post by pjmlp »

rramadass wrote: post #27
pjmlp wrote: post #20

Earlier quoted context omitted.

Unfortunely I have seen plenty of counter examples since 1991. Starting with RatC from "Book on C", 1988 edition, over to Turbo C 2.0 in 1991, all the way to modern times. That is just not how most C codebases look like.

Nope, you are just generalizing your opinion which is not quite true. My (and my colleagues) experience studying/programming C/C++ from the beginning-90's has been pretty good. When the PC explosion happened, a lot of programmers without any CS background started with C programming and hence of course there is a lot of code (usually not long lasting) which do not adhere to software engineering principles. But quite a…

Each one is their own anecdote.

I have also all those books and magazines, pitty most coders of the code I have seen on my lifetime don't.

The regular developers, those that don't give a shit online forums exist, other than Stack Overflow, and go home to do non computer related stuff after work.

Post reply on HN