3 ms·

How can you be convinced if you're only running the control in an experiment?

by lucidguppy 9y ago

jstimpfle 9y ago
It's not an experiment.
- todd8 9y ago
  I don't believe that lucidguppy was saying that your system was an experiment. Instead, it would be interesting to try implementing your system in a second language so you could compare and contrast the differences. (Of course, in the real-world one often doesn't have the luxury of doing this.)
  - jstimpfle 9y ago
    Ok, so my conviction comes from the fact that the code is super straight-forward and I don't have to deal with the complexities of a managed language's run-time system (like tuning the garbage collector or scheduler, using synchronisation primitives, depending on the ecosystem/using terrible bindings, etc). All investment is just a page of code using the Windows Fiber API, and the scheduler ist just 10 lines of code doing round-robin scheduling. Which is totally fine right now, and there's the added benefit of being in total control and being able to make adjustments if they are needed in the future. Since the scheduling is non-preemptive, threads are not allowed to block. But only a synchronous, blocking coding style is maintainable, so threads use wrapper functions to execute slow operations. The wrapper functions have a synchronous interface, but internally they call asynchronous functions, and unless the request can be served immediately, they call the scheduler. The wrapper functions make another 50 lines (so far) of really simple bullet-proof maintainable code. It's really like Javascript technically (non-preemptive scheduling), but you don't have to do callback chaining. You just write your code in an ordinary synchronous blocking style. Think about that. You write thread-heavy interactive C code that is much more maintainable than Javascript code. And of course, much more maintainable than clumsy OS threads - no management, no synchronisation primitives and no excessive copying between threads. On top of that, the scheduling is deterministic. All with 100 lines of straightforward infrastructure code. The only boilerplate in the project comes from using Qt/Qml. (If you're on POSIX and can't use the Windows Fiber API, you can depend on the deprecated makecontext/getcontext/setcontext API, or write a little inline assembly. It's not a big deal either way, since it's really just a few lines of code that are neatly separated from the rest of the system).
    - ac2u 9y ago
      Would be nice to see a blog post expanding on this a little more with more examples and some basic diagrams.

How can you be convinced if you're only running the control in an experiment?

jstimpfle 9y ago

It's not an experiment.

todd8 9y ago
I don't believe that lucidguppy was saying that your system was an experiment. Instead, it would be interesting to try implementing your system in a second language so you could compare and contrast the differences. (Of course, in the real-world one often doesn't have the luxury of doing this.)
- jstimpfle 9y ago
  Ok, so my conviction comes from the fact that the code is super straight-forward and I don't have to deal with the complexities of a managed language's run-time system (like tuning the garbage collector or scheduler, using synchronisation primitives, depending on the ecosystem/using terrible bindings, etc). All investment is just a page of code using the Windows Fiber API, and the scheduler ist just 10 lines of code doing round-robin scheduling. Which is totally fine right now, and there's the added benefit of being in total control and being able to make adjustments if they are needed in the future. Since the scheduling is non-preemptive, threads are not allowed to block. But only a synchronous, blocking coding style is maintainable, so threads use wrapper functions to execute slow operations. The wrapper functions have a synchronous interface, but internally they call asynchronous functions, and unless the request can be served immediately, they call the scheduler. The wrapper functions make another 50 lines (so far) of really simple bullet-proof maintainable code. It's really like Javascript technically (non-preemptive scheduling), but you don't have to do callback chaining. You just write your code in an ordinary synchronous blocking style. Think about that. You write thread-heavy interactive C code that is much more maintainable than Javascript code. And of course, much more maintainable than clumsy OS threads - no management, no synchronisation primitives and no excessive copying between threads. On top of that, the scheduling is deterministic. All with 100 lines of straightforward infrastructure code. The only boilerplate in the project comes from using Qt/Qml. (If you're on POSIX and can't use the Windows Fiber API, you can depend on the deprecated makecontext/getcontext/setcontext API, or write a little inline assembly. It's not a big deal either way, since it's really just a few lines of code that are neatly separated from the rest of the system).
  - ac2u 9y ago
    Would be nice to see a blog post expanding on this a little more with more examples and some basic diagrams.