On Friday, 17 June 2022 at 16:37:26 UTC+1 Rob wrote:
Rob, if you break the timing dependency out - that is, have the button
cb return "instantly" and then perform the time consuming
computations in a different thread (say) does that then make things
"work" - i.e. is it is possible to demonstrate that it is timing that
is the crux here, or is there something more going on?
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...
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 firstname.lastname@example.org.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/0310b708-e59c-4060-8422-0ff3eac1c36an%40googlegroups.com.
[ Direct Link to Message ]