7 ms·

> multicore architecture This works if browser is the only application that runs on machine. So this is limiting possible use cases (like Electron) quite a lot

> multicore architecture This works if browser is the only application that runs on machine. So this is limiting possible use cases (like Electron) quite a lot. > low memory consumption Sciter's Quark (https://quark.sciter.com https://quark.sciter.com) - 5 MB binary and 28 MB RAM by default is probably the lowest what you can get for HTML/CSS/script engine.

chrisseaton 6y ago
> This works if browser is the only application that runs on machine. I don't understand what you mean - individual applications within a multi-application system can absolutely utilise multiple cores. It isn't true that it won't work. The kernel schedules all the tasks of all applications across the available cores. And even if you have many applications running, most of them don't need multiple cores all the time, so it makes sense for each application to be able to use as many cores as possible, when the user is looking at it and doing something. For example if I'm using my text editor and browsing docs. My text editor only needs tiny a fraction of a core every now and again, but each time I navigate it'd be great if the browser temporarily used all sixteen cores to do that as quickly as possible.
- paulryanrogers 6y ago
  While true one concern is that proliferation of threads/processes per application could reach the point where context switching and thread management alone consume a lot of the capacity. IIRC super computers often need special interconnects and software to minimize the distribution costs of so many cores.
  - PaulDavisThe1st 6y ago
    "supercomputers" are designed (typically) to run CPU-bound tasks. User applications with GUIs are almost never CPU-bound, so the comparison is not really appropriate.
    - paulryanrogers 6y ago
      > User applications with GUIs are almost never CPU-bound, so the comparison is not really appropriate. Video conferencing, JS heavy web browsing, video editing, and gaming are all examples of CPU-intense applications that are becoming increasingly common
      - PaulDavisThe1st 6y ago
        1) I don't tend to think of games as applications with GUIs, but you're right, they really are, and yes, they can be CPU-bound sometimes. However, a game that was actually CPU-bound would be very unpleasant to play. That's not true for the applications that run on super-computers: they just take longer to run that someone would like. 2) video conferencing is not CPU-bound unless you're doing 1-to-many/many-to-1 feeds locally. 3) JS heavy web browsing ... 'nuff said. 4) Very few people do video editing that is CPU bound. Certainly for video editors, it is an issue. Clearly, I should have said: "The majority of applications used by the majority of users are rarely CPU-bound" But more importantly: even the exceptions are really nothing like "supercomputer workloads".
      - cmrdporcupine 6y ago
        Of the things you listed only JS would count as "CPU intense" in the strict definition of CPU as microprocessor unit; the others are typically bound on specialized hardware -- hardware video encoders/decoders, and GPUs. And, having done plenty of video dev work recently, beyond the codecs and GPUs, it's also memory bandwidth/lock contention/data path that's really key for getting good video performance. We're almost never decoding or encoding video by CPU anymore. If we can avoid it. Arguably with JS heavy web browsing you're also looking at memory bandwidth or lock contention as a key limitation -- garbage collection in the JS interpreter, fetching and dispatching opcodes, etc. CPU is only part of the story. Life just became so so very complicated in the 90s when CPU performance started to compltely outstrip main memory and bus performance.
    - chrisseaton 6y ago
      > User applications with GUIs are almost never CPU-bound I watch live streams of music producers working with DAWs and they actually end up needing to offload synthesis and filtering to multiple separate machines as they can't do it on one. Also if you think things aren't CPU-bound then why do you think people spend hundreds or thousands of dollars on CPUs?
  - wolrah 6y ago
    > While true one concern is that proliferation of threads/processes per application could reach the point where context switching and thread management alone consume a lot of the capacity. Have you ever played around with BeOS or its community-driven successor Haiku? They are what's called "pervasively multithreaded" such that every single widget in the standard UI toolkit has its own thread. It's literally possible in BeOS/Haiku to lower the priority of a single radio button. This is an OS designed around early '90s era dual CPU hardware. Considering that they made this choice at that time and still ended up with an OS that's remembered primarily for its performance and responsiveness when multitasking it seems hard to believe that threading overhead itself is too big of a deal even at extreme levels. > IIRC super computers often need special interconnects and software to minimize the distribution costs of so many cores. This is for entirely different reasons. The specialized supercomputer interconnects exist to minimize the cost of sharing data across nodes. Basically they provide DMA over a network fabric. It only really matters once your workload is large enough that you can't just throw a larger single machine at it but also impossible to split up in to smaller chunks that would fit within individual nodes. If you're familiar with NUMA in multi-socket systems (or first-gen Epyc/Threadripper) you can think of the supercomputer interconnects as basically extending that principle up another tier to encompass multiple independent servers.
    - waddlesplash 6y ago
      > It's literally possible in BeOS/Haiku to lower the priority of a single radio button. This is not true, individual widgets most definitely do not have their own threads. Windows each have their own threads, which is indeed different from virtually every other OS which does not have this (or even allow off-the-main-thread UI operations.)
      - ygra 6y ago
        WPF can have a different Dispatcher per window, but inded, that's a fairly rare capability. I can't say I've ever needed to use this, though.
        int_19h 6y ago
- c-smile 6y ago
  It depends... On Raspberry Pi for example (ARM device) parallel compilation (make ... -j 4) makes its UI completely non-responsive. The only reasonable option for UI rendering these days (high-DPI monitors) is to delegate rasterization to GPU. CPU is for running application logic. If you would do UI on CPU then this will be the only task your CPU will do. E.g. animations require stable frame rate (60 FPS or more) so UI must run on highest possible priority on your OS.
  - deleted 6y ago
    [deleted]
  - freeone3000 6y ago
    -j4 on a pi freezes the UI because you're using 100% of all cores continually for minutes - smaller chunks of work and better scheduling (or the "trick" of -j3) fixes this, and it's doubtful that a browser uses 100% of CPU for any length of time.
    - c-smile 6y ago
      I know how to tackle such problems. My comment is rather about "multi-core UI". Many UI tasks have almost real-time requirements (animations, synchronized rendering, video) so they behave as "make -j 4" meaning that the device is just busy rasterizing pixels but not doing anything meaningful. And all that while we have dedicated powerful (YMMV) GPU that supposed to do those for us.
      - chrisseaton 6y ago
        I don't think you can run layout code on a GPU effectively. It isn't a data-parallel problem. Obviously actual pixel rendering is is done on a GPU - why would you do it it anywhere else, but that's not what we're talking about here.
      - freeone3000 6y ago
        It's real-time but not particularly CPU-hungry. Playback an animation and see how much CPU time it actually uses - you'll end up yielding most of the time, so other apps can use the remainder just fine.
fabiospampinato 6y ago
> Sciter's Quark (https://quark.sciter.com https://quark.sciter.com) - 5 MB binary and 28 MB RAM by default is probably the lowest what you can get for HTML/CSS/script engine. That doesn't even run standard HTML/CSS/JavaScript. That fact alone would make me completely ignore it for any possible application.
- c-smile 6y ago
  Yes, it uses its own script yet supports HTML5 and CSS2.1 + some CSS3 modules. But if you just need to create some relatively small utility, let's say, calculator.exe then it is pretty adequate for the task. If you want to run something that is designed for Web browser then you need browser and server (Electron or Atom for example).
  - fabiospampinato 6y ago
    > But if you just need to create some relatively small utility, let's say, calculator.exe then it is pretty adequate for the task. If making a calculator with web technologies is more important to me than making a very resource efficient one why would I _ever_ use Sciter for this that doesn't give me not proper web technologies to use and neither an actually resource-efficient calculator?
    - c-smile 6y ago
      That's probably true for calculator. But if you need some aside application for communication (e.g. Slack, Skype, whatever) accompanying your main workflow then it is better if that will consume as less resources as possible. But even for more or less feature rich calculator, e.g. something like personal accounting/finances utility, you'd better have flexible UI.
      - fabiospampinato 6y ago
        > then it is better if that will consume as less resources as possible. Which would automatically mean Sciter would not be a good fit for this. > you'd better have flexible UI. If that's more important then why not going with proper web technologies?
est31 6y ago
> 5 MB binary and 28 MB RAM by default I wonder how WPE [1] compares to that. [1]: https://webkit.org/wpe/ https://webkit.org/wpe/
BeKindAndLearn 6y ago
It's always nice to see you around! Usually I catch threads too late to participate. Sciter is a really cool technology. However I've always wanted to ask you - do you ever feel that your deviation from standards has reduced your market? I was considering Sciter for a project previously, but ultimately decided against it because it required me to write two separate implementations for desktop and browser. There's obviously benefits from deviating from HTML / CSS / JS, they're very much products of history. Sciter's native (and seamless) custom HTML tags, some built-in preprocessing, being more immediately feature complete, all just wonderful. I'd just like to hear your specific reasoning, though. And if you're able to comment on it, how many people maintain this project? It seems like a huge task, but most of the discussions I've seen hint toward it just being yourself. Finally, how is accessibility support? This seems like a big point, but it's not directly addressed in the documentation I've seen. In one forum post I saw you say that Sciter assigns some screen reader semantics based on a custom behavior tag in the CSS?
- c-smile 6y ago
  > deviation from standards has reduced your market Just an example why that happens: Sciter got flexes and grid 10 years ago as they are the must for desktop UI. Web platform got them practically only in couple of last years. And it is simply to late to change anything - many customers rely on them. But its quite easy to solve this problem using @media sciter {...} sections. Features are easily transformable: https://terrainformatica.com/w3/flex-layout/flex-vs-flexbox.htm https://terrainformatica.com/w3/flex-layout/flex-vs-flexbox.... Same is about script. classes, namespaces, symbols, async/await were in Sciter 7 years ago - I cannot change too much there. Support of existing customers is very critical for me. > how many people maintain this project? I did Sciter by myself only. Beside of customers there are three independent developers (Russia, Brazil and France) that requested and have access to Sciter source tree. I am accepting patches from them and customers. 3 AV vendors independently did security audit of the code. Yet Symantec (Norton Antivirus) provided Accessibility support implementation as for them Section 508 was the must.
  - BeKindAndLearn 6y ago
    Thank you for the quick response!

chrisseaton 6y ago

> This works if browser is the only application that runs on machine. I don't understand what you mean - individual applications within a multi-application system can absolutely utilise multiple cores. It isn't true that it won't work. The kernel schedules all the tasks of all applications across the available cores. And even if you have many applications running, most of them don't need multiple cores all the time, so it makes sense for each application to be able to use as many cores as possible, when the user is looking at it and doing something. For example if I'm using my text editor and browsing docs. My text editor only needs tiny a fraction of a core every now and again, but each time I navigate it'd be great if the browser temporarily used all sixteen cores to do that as quickly as possible.

paulryanrogers 6y ago
While true one concern is that proliferation of threads/processes per application could reach the point where context switching and thread management alone consume a lot of the capacity. IIRC super computers often need special interconnects and software to minimize the distribution costs of so many cores.
- PaulDavisThe1st 6y ago
  "supercomputers" are designed (typically) to run CPU-bound tasks. User applications with GUIs are almost never CPU-bound, so the comparison is not really appropriate.
  - paulryanrogers 6y ago
    > User applications with GUIs are almost never CPU-bound, so the comparison is not really appropriate. Video conferencing, JS heavy web browsing, video editing, and gaming are all examples of CPU-intense applications that are becoming increasingly common
    - PaulDavisThe1st 6y ago
      1) I don't tend to think of games as applications with GUIs, but you're right, they really are, and yes, they can be CPU-bound sometimes. However, a game that was actually CPU-bound would be very unpleasant to play. That's not true for the applications that run on super-computers: they just take longer to run that someone would like. 2) video conferencing is not CPU-bound unless you're doing 1-to-many/many-to-1 feeds locally. 3) JS heavy web browsing ... 'nuff said. 4) Very few people do video editing that is CPU bound. Certainly for video editors, it is an issue. Clearly, I should have said: "The majority of applications used by the majority of users are rarely CPU-bound" But more importantly: even the exceptions are really nothing like "supercomputer workloads".
    - cmrdporcupine 6y ago
      Of the things you listed only JS would count as "CPU intense" in the strict definition of CPU as microprocessor unit; the others are typically bound on specialized hardware -- hardware video encoders/decoders, and GPUs. And, having done plenty of video dev work recently, beyond the codecs and GPUs, it's also memory bandwidth/lock contention/data path that's really key for getting good video performance. We're almost never decoding or encoding video by CPU anymore. If we can avoid it. Arguably with JS heavy web browsing you're also looking at memory bandwidth or lock contention as a key limitation -- garbage collection in the JS interpreter, fetching and dispatching opcodes, etc. CPU is only part of the story. Life just became so so very complicated in the 90s when CPU performance started to compltely outstrip main memory and bus performance.
  - chrisseaton 6y ago
    > User applications with GUIs are almost never CPU-bound I watch live streams of music producers working with DAWs and they actually end up needing to offload synthesis and filtering to multiple separate machines as they can't do it on one. Also if you think things aren't CPU-bound then why do you think people spend hundreds or thousands of dollars on CPUs?
- wolrah 6y ago
  > While true one concern is that proliferation of threads/processes per application could reach the point where context switching and thread management alone consume a lot of the capacity. Have you ever played around with BeOS or its community-driven successor Haiku? They are what's called "pervasively multithreaded" such that every single widget in the standard UI toolkit has its own thread. It's literally possible in BeOS/Haiku to lower the priority of a single radio button. This is an OS designed around early '90s era dual CPU hardware. Considering that they made this choice at that time and still ended up with an OS that's remembered primarily for its performance and responsiveness when multitasking it seems hard to believe that threading overhead itself is too big of a deal even at extreme levels. > IIRC super computers often need special interconnects and software to minimize the distribution costs of so many cores. This is for entirely different reasons. The specialized supercomputer interconnects exist to minimize the cost of sharing data across nodes. Basically they provide DMA over a network fabric. It only really matters once your workload is large enough that you can't just throw a larger single machine at it but also impossible to split up in to smaller chunks that would fit within individual nodes. If you're familiar with NUMA in multi-socket systems (or first-gen Epyc/Threadripper) you can think of the supercomputer interconnects as basically extending that principle up another tier to encompass multiple independent servers.
  - waddlesplash 6y ago
    > It's literally possible in BeOS/Haiku to lower the priority of a single radio button. This is not true, individual widgets most definitely do not have their own threads. Windows each have their own threads, which is indeed different from virtually every other OS which does not have this (or even allow off-the-main-thread UI operations.)
    - ygra 6y ago
      WPF can have a different Dispatcher per window, but inded, that's a fairly rare capability. I can't say I've ever needed to use this, though.
      - int_19h 6y ago
c-smile 6y ago
It depends... On Raspberry Pi for example (ARM device) parallel compilation (make ... -j 4) makes its UI completely non-responsive. The only reasonable option for UI rendering these days (high-DPI monitors) is to delegate rasterization to GPU. CPU is for running application logic. If you would do UI on CPU then this will be the only task your CPU will do. E.g. animations require stable frame rate (60 FPS or more) so UI must run on highest possible priority on your OS.
- deleted 6y ago
  [deleted]
- freeone3000 6y ago
  -j4 on a pi freezes the UI because you're using 100% of all cores continually for minutes - smaller chunks of work and better scheduling (or the "trick" of -j3) fixes this, and it's doubtful that a browser uses 100% of CPU for any length of time.
  - c-smile 6y ago
    I know how to tackle such problems. My comment is rather about "multi-core UI". Many UI tasks have almost real-time requirements (animations, synchronized rendering, video) so they behave as "make -j 4" meaning that the device is just busy rasterizing pixels but not doing anything meaningful. And all that while we have dedicated powerful (YMMV) GPU that supposed to do those for us.
    - chrisseaton 6y ago
      I don't think you can run layout code on a GPU effectively. It isn't a data-parallel problem. Obviously actual pixel rendering is is done on a GPU - why would you do it it anywhere else, but that's not what we're talking about here.
    - freeone3000 6y ago
      It's real-time but not particularly CPU-hungry. Playback an animation and see how much CPU time it actually uses - you'll end up yielding most of the time, so other apps can use the remainder just fine.

fabiospampinato 6y ago

> Sciter's Quark (https://quark.sciter.com https://quark.sciter.com) - 5 MB binary and 28 MB RAM by default is probably the lowest what you can get for HTML/CSS/script engine. That doesn't even run standard HTML/CSS/JavaScript. That fact alone would make me completely ignore it for any possible application.

c-smile 6y ago
Yes, it uses its own script yet supports HTML5 and CSS2.1 + some CSS3 modules. But if you just need to create some relatively small utility, let's say, calculator.exe then it is pretty adequate for the task. If you want to run something that is designed for Web browser then you need browser and server (Electron or Atom for example).
- fabiospampinato 6y ago
  > But if you just need to create some relatively small utility, let's say, calculator.exe then it is pretty adequate for the task. If making a calculator with web technologies is more important to me than making a very resource efficient one why would I _ever_ use Sciter for this that doesn't give me not proper web technologies to use and neither an actually resource-efficient calculator?
  - c-smile 6y ago
    That's probably true for calculator. But if you need some aside application for communication (e.g. Slack, Skype, whatever) accompanying your main workflow then it is better if that will consume as less resources as possible. But even for more or less feature rich calculator, e.g. something like personal accounting/finances utility, you'd better have flexible UI.
    - fabiospampinato 6y ago
      > then it is better if that will consume as less resources as possible. Which would automatically mean Sciter would not be a good fit for this. > you'd better have flexible UI. If that's more important then why not going with proper web technologies?

est31 6y ago

> 5 MB binary and 28 MB RAM by default I wonder how WPE [1] compares to that. [1]: https://webkit.org/wpe/ https://webkit.org/wpe/

BeKindAndLearn 6y ago

It's always nice to see you around! Usually I catch threads too late to participate. Sciter is a really cool technology. However I've always wanted to ask you - do you ever feel that your deviation from standards has reduced your market? I was considering Sciter for a project previously, but ultimately decided against it because it required me to write two separate implementations for desktop and browser. There's obviously benefits from deviating from HTML / CSS / JS, they're very much products of history. Sciter's native (and seamless) custom HTML tags, some built-in preprocessing, being more immediately feature complete, all just wonderful. I'd just like to hear your specific reasoning, though. And if you're able to comment on it, how many people maintain this project? It seems like a huge task, but most of the discussions I've seen hint toward it just being yourself. Finally, how is accessibility support? This seems like a big point, but it's not directly addressed in the documentation I've seen. In one forum post I saw you say that Sciter assigns some screen reader semantics based on a custom behavior tag in the CSS?

c-smile 6y ago
> deviation from standards has reduced your market Just an example why that happens: Sciter got flexes and grid 10 years ago as they are the must for desktop UI. Web platform got them practically only in couple of last years. And it is simply to late to change anything - many customers rely on them. But its quite easy to solve this problem using @media sciter {...} sections. Features are easily transformable: https://terrainformatica.com/w3/flex-layout/flex-vs-flexbox.htm https://terrainformatica.com/w3/flex-layout/flex-vs-flexbox.... Same is about script. classes, namespaces, symbols, async/await were in Sciter 7 years ago - I cannot change too much there. Support of existing customers is very critical for me. > how many people maintain this project? I did Sciter by myself only. Beside of customers there are three independent developers (Russia, Brazil and France) that requested and have access to Sciter source tree. I am accepting patches from them and customers. 3 AV vendors independently did security audit of the code. Yet Symantec (Norton Antivirus) provided Accessibility support implementation as for them Section 508 was the must.
- BeKindAndLearn 6y ago
  Thank you for the quick response!