FLTK logo

Re: OT thoughts - was Re: [fltk.coredev] Fl_Choice initiates infinite loop

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 All Forums  |  Back to fltk.coredev  ]
 
Previous Message ]New Message | Reply ]Next Message ]

Re: OT thoughts - was Re: Fl_Choice initiates infinite loop Rob McDonald Jun 20, 2022  
 
On Monday, June 20, 2022 at 12:38:49 AM UTC-7 imacarthur wrote:
I don't see a practical way to do this (certainly not in the short term).  My program is not thread safe and we take a long time to come back in a number of situations.  This program and its ancestors have been using FLTK (and XForms and SGI Forms before that) since the early 1990's -- at different times, computers get faster, but our calculations also get more complex.  Most things maintain the illusion of happening 'instantly', but users can create arbitrarily complex models -- which can take time to update.

What I'm about to add is way off-topic for the original thread, and probably not all that useful either, but here goes anyway...

You say "at different times, computers get faster", but that's not quite what happens any more - CPU clocks hit the 3 ~ 3.5GHz level many years ago now and haven't really gone much higher since - sure, there have been incremental improvements in microcode execution, branch prediction, pipelining, etc. that have each allowed modern CPUs do do a bit more per-clock cycle, but the raw single-thread performance is still largely determined by raw clock speed, which hasn't really changed all that much (indeed, in practice a lot of modern cores have lower nominal clock speeds in a drive to lower the TDP.)

Rather, modern CPUs have become much "wider" rather than "faster" - they're still using all the extra transistors that Moore promised us, but not to go faster...
But the only way to get at that extra capacity is to use more threads - which is a nuisance, but an apparently necessary one.
So if your program is being tasked with increasingly complex models to execute, it may well be worth the pain to see if those tasks can be spun into their own threads in some safe way...

This is a fair point.

I will have to start thinking about ways to make this happen.

There are admittedly a lot of things that can be done to make my program faster in places -- lots of them are easier than making it thread safe.  Unfortunately, while there is sometimes funding to add features, there is seldom funding to buy down technical debt.

I also struggle a bit with what a multi-threaded use case would be like.  In my program, you are interacting with a central model.  When you make a change, it takes a certain amount of time.  It doesn't really make sense to start making the next change before the model has updated for the previous one -- you're somewhat forced to serialize around the user's ability to see the impact of their change.

Think about applying a filter or blur in Photoshop or Gimp.  If it takes 1.5 seconds for the filter to be applied to your image -- does it make sense for the user to be already applying the next filter?  In many ways, the best thing to do is show the user an hourglass (or spinning beachball) and make them wait.

Rob


--
You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/e3032bfa-faea-490b-853e-461972a08fban%40googlegroups.com.
Direct Link to Message ]
 
     
Previous Message ]New Message | Reply ]Next Message ]
 
 

Comments are owned by the poster. All other content is copyright 1998-2024 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.