Winstep

Software Technologies


 Winstep Forums


Print view
Board index : Winstep Forums : General Discussion  [ 3 posts ]
Author Message
 Post subject: 2-Dimensional "architecture" question
PostPosted: Sat Mar 09, 2019 11:14 pm 
Offline

Joined: Sat Mar 09, 2019 6:56 pm
Posts: 2
Note that I was prepared to post this in the "Coming From ObjectDock Pain Points" thread, but that was looking too much like a soap-opera. ;)

Should our esteemed author/moderator "WINSTEP" (can I call you just "Win"?) decide that this should be *two* threads, I would happily accept that judgement... but here goes:

1) As someone who has spent many years with RocketDock (back to the days when the two authors were still posting in their forum), I have to say I am amazed at the thoroughness and "thought-out-edness" of what I believe is properly termed "Winstep Nexus", in terms of UI, looks, functionality (with one possible caveat, see below) - BUT (you knew there had to be one, right? ;)) - I am interested to hear about the internal architecture and possibly the implementation language also, should our author care to share some of these details.

My specific issue has to do with what I consider to be an extreme CPU usage level - this is coming from a Docklet implementer, BTW - and to be clear, is not gross in an absolute sense: ~3% continuous on my Core i7-7700 under Windows 10 Pro. The dual (and I believe connected) indicators of this are the CPU usage report itself, as well as the extraordinarily high # of "context switches": 2.2K - 2.5K per second!

(A relevant detail: the ONLY installed apps/docklets I have are the "Weather" one, which seems to only want to update hourly, so shouldn't be a source of continuous activity every second, and the "Screenshot" one, similarly inactive until called upon.)

Besides the fact that the way-less-capable-but-still-fairly-cool RocketDock runs with essentially 0% CPU and 1-5 context switches per second, my perspective is based on the fact that there isn't really anything going on that should call for this level of continuous activity.

RocketDock with my own Docklet running - which itself generates a timer tick every second - has... 1 context switch per second. ;) Heavyweight Web browsers with "chatty" pages open can generate possibly 100s of context switches, and a few percent CPU... you see where I am going. Why do we care? Everything about modern PCs/tablets/phones is about [sometimes seriously] smart power management, and that in turn has as a large component the ability to power down cores not in use. An app running that demands to be woken up 1000s of times a second, even if those are "anything to do? nope, back to sleep" threads is working at cross-purposes to power management.

2) Again, the fact that I am so impressed with this product is why I am here... and asking my other "architecture" question: I fear the answer is no, but there is still a lot to explore here - *is* there any sort of "open" interface specification for the Winstep Nexus -related family? So that I could, for instance, either extend my free and open source Docklet or at worst write a new version of same - to run in this environment?

Note that I am *not* someone with a political/social axe to grind WRT "Open Source" - for instance, the author of the much-used HWiNFO app and I reached an agreement where I could make my free Docklet available - including support for HWiNFO - by *not* publishing the actual details of his "3rd-party" interface... not a perfect resolution, but one we were both able to live with.

To sum up, I am amazed with Winstep Nexus as a dock, but the closed architecture (*if it indeed is!*) seems at odds with today's trends... and, sniff, I can't run my own Docklet (RXMDocklet, on Github), which is making me feel like a limb has been removed while I am at my computer. :(


Back to top
 Profile  
 
 Post subject: Re: 2-Dimensional "architecture" question
PostPosted: Sun Mar 10, 2019 5:17 am 
Offline
Site Admin
User avatar

Joined: Thu Feb 26, 2004 8:30 pm
Posts: 10559
RDaneel2 wrote:
Note that I was prepared to post this in the "Coming From ObjectDock Pain Points" thread, but that was looking too much like a soap-opera. ;)


LOL. Glad you decided to post it on a separate thread.

RDaneel2 wrote:
1) As someone who has spent many years with RocketDock (back to the days when the two authors were still posting in their forum)


RocketDock was/is an excelent dock, pity it became abandonware and, even worse, that the authors recently decided to delete the RocketDock gallery with the thousands of themes, icons, etc, in it (I even offered to host it, but they declined saying they had a safe-keeping responsibility to their users. Fair enough).

Let this be a warning to what usually happens when your software does not have a commercial side to keep it alive.

RDaneel2 wrote:
~3% continuous on my Core i7-7700 under Windows 10 Pro.


Is that 3% of ONE core or 3% as reported by the Details tab in Task Manager? There is a huge difference, since reported CPU usage of a process is normally a value divided by the number of cores in the CPU (double that if HT is enabled and supported, which should be in your case).

So, 3% of one core is nothing, but 3% reported in Task Manager in a 4 core CPU with HT enabled means the process is actually using about 25% of a single core: 3% x 8 cores (4 physical + 4 virtual) = 24% - that amount of *continuous* CPU usage is already not normal.

Also, is the CPU overclocked? Are CPU power states enabled? Is it always running at max turbo speed? Are all cores locked at the same speed?

Calculating actual CPU usage of a process on modern processors is anything but straightforward these days. :)

RDaneel2 wrote:
The dual (and I believe connected) indicators of this are the CPU usage report itself, as well as the extraordinarily high # of "context switches": 2.2K - 2.5K per second!


Context switches happen when the CPU jumps from one thread to another, and this can happen for a multitude of reasons. A much more reliable and revealing indicator of actual CPU usage over time (at least when you compare it to other 'always running' applications) would be the 'CPU Time' column in Task Manager.

RDaneel2 wrote:
Besides the fact that the way-less-capable-but-still-fairly-cool RocketDock runs with essentially 0% CPU and 1-5 context switches per second, my perspective is based on the fact that there isn't really anything going on that should call for this level of continuous activity.


Ok, let's establish some background here then:

I used to code in Assembly Z80 back in the Zx Spectrum days. We're talking a time where CPUs ran at 3.5/4 Mhz (yes, Mhz, NOT Ghz) and 32KB of RAM (yes, KB, NOT GB lol) was the norm, so every T-State and every byte of memory usage counted. I wrote a Basic Interpreter in machine code that managed to run faster on a 3.5 Mhz Z80 CPU than the Amstrad's Basic interpreter on a Z80 running at 4 Mhz (and the Amstrad Basic Interpreter was considered extremely fast at the time).

This 'tough shall not waste' mindset has stayed with me throughout all these years.

Now, here is the thing: Winstep started back in 1999 when I decided to write a small menu application to emulate under Windows 98 the look & feel of menus in Steve Job's NeXT OS. That's how NextSTART (now a component of Winstep Xtreme) was born. WindowBlinds was still in beta back then, hadn't even reached v1.0, and all it did was skin window borders, titlebars and titlebar buttons. There was nothing that did skinnable menus.

Because this was supposed to be just for me and a friend in the US who was interested in the same thing and to initially work just as an 'overlay' to an existing application called PowerPro, I used the tool that would allow me to do this as quickly as possible and was, at the time, the most popular programming language in the world bar none: Visual Basic.

Had I known back then what that little menu app would turn into or that Microsoft would eventually kill classic VB, I would have used C++ instead. But I didn't, and hindsight is, of course, 20/20 vision.

So, Winstep applications are written in VB 5 (although a huge portion of the code is made by calls to the Windows API). This by itself means many of the things happening in the background are beyond my control, as they are managed by the VB5 runtime.

The thing is, VB5, as a compiled language, is actually pretty fast, almost as fast as pure C++ code, and suits these type of applications very well in fact. Try writing the same application in .NET and you will fail: the result will be a hugely bloated and extremely slow mess.

Anyway, as I said the mindset of 'though shall not waste' from the Z80 days is still with me, so I employ every trick in the book to make the application as fast as possible, and also to waste as little CPU cycles as possible.

Wherever possible, anything that is not in use in the application by the user does not use any resources (timers are turned off and calls are not made).

This said, do not be deceived by how simple Nexus might look at first sight: behind that pretty face there is a HUGE amount of functionality, something you will discover and learn to appreciate the more you use the application.

It also does a TON of things NONE of the other Windows docks do, and does them very well. For instance, there is a docklet for RocketDock that allows you to add animated icons to the dock (animated icons are natively supported in Winstep applications, by the way, and can be used just as if they were normal icons). Now put two or three of those in RocketDock and RocketDock will slow to a CRAWL. Put 10 or more of those in Nexus and everything will keep on running just as smoothly as it was (but, of course, memory usage will go through the roof, as each animated icon uses literally a TON of memory).

Also, check out *real time* icon reflections and the 20+ mouseover, launch, attention and delete effects (that no other Windows dock has either). That you can even combine those animations with the magnify effect without everything slowing to a crawl is a testament to how fast the application really is, and how careful I am to make the fastest code possible.

Now that this is out of the way, let's continue. :)

RDaneel2 wrote:
Everything about modern PCs/tablets/phones is about [sometimes seriously] smart power management, and that in turn has as a large component the ability to power down cores not in use. An app running that demands to be woken up 1000s of times a second, even if those are "anything to do? nope, back to sleep" threads is working at cross-purposes to power management.


And laptops plus battery usage are one of the reasons I added two 'Power Saving' modes (Normal and Ultra) to Winstep applications, which can be turned on either manually or automatically. The normal power saving mode doesn't affect things much in terms of usability (there is a full list of what it does in the link above) but still allows you to save up to 75% in CPU - and thus battery - usage.

Otherwise power consumption for desktops is pretty much irrelevant. Oh, and you can't have your lunch and eat it too. You must make choices.

RDaneel2 wrote:
2) Again, the fact that I am so impressed with this product is why I am here... and asking my other "architecture" question: I fear the answer is no, but there is still a lot to explore here - *is* there any sort of "open" interface specification for the Winstep Nexus -related family? So that I could, for instance, either extend my free and open source Docklet or at worst write a new version of same - to run in this environment?


And the answer is indeed No.

There are two reasons for this, one technical and one deliberate:

1. VB does not allow you to export functions. This alone prevents the usage of 3rd party docklets, at least using the OD model.

On the other hand, I did learn how to bypass this by 'hacking' the VB5 linker. But then there is reason number 2:

2. Many docklets are poorly coded and they run in the process space of the main application. This means a poorly coded docklet can bring down the host application, make it leak memory, etc... Users are quick to point the finger even when they have no idea of what is going on, and a buggy 3rd party docklet in their minds would mean a buggy application.

Not supporting 3rd party docklets allows me to have full control of the application and also the quality of the existing docklets/modules. If anything goes wrong I only have myself to blame (most of the time, lol, as 3rd party applications can still inject buggy DLLs into your own process, e.g.; Asus GPU Tweak II and others).

The price I pay for this is a relative scarcity of modules/docklets, of course, since there is only so much I can focus on at a time.

RDaneel2 wrote:
Note that I am *not* someone with a political/social axe to grind WRT "Open Source" - for instance, the author of the much-used HWiNFO app and I reached an agreement where I could make my free Docklet available - including support for HWiNFO - by *not* publishing the actual details of his "3rd-party" interface... not a perfect resolution, but one we were both able to live with.


Yep, some hardware monitoring applications allow 3rd party apps to access their data via Memory Mapped Files, etc... I never tried implementing a module\widget to take advantage of this for a variety of reasons though.

RDaneel2 wrote:
To sum up, I am amazed with Winstep Nexus as a dock, but the closed architecture (*if it indeed is!*) seems at odds with today's trends... and, sniff, I can't run my own Docklet (RXMDocklet, on Github), which is making me feel like a limb has been removed while I am at my computer. :(


Sorry about that. :(

As for open source, or freeware, see how far that got us - all the free docks are dead and have been for years (except Nexus, of course, but that only because it is backed up by their commercial bigger brothers, Nexus Ultimate and Winstep Xtreme). Heck, even OD is dead (but that for different reasons, i.e.; the original developer left Stardock).

_________________
Jorge Coelho
Winstep Xtreme - Xtreme Power!
http://www.winstep.net - Winstep Software Technologies


Back to top
 Profile WWW 
 
 Post subject: Re: 2-Dimensional "architecture" question
PostPosted: Mon Mar 11, 2019 2:31 am 
Offline

Joined: Sat Mar 09, 2019 6:56 pm
Posts: 2
Thanks for the amazingly detailed and informative reply, "Win" ;) - even if it contained "bad news" from my perspective.

Regarding numbers and measurements, I had meant to mention that I am dependent on Process Hacker for all CPU/memory usage reporting and tracking - it is an amazingly flexible and performant app for this, and finally replaced the also-excellent Process Explorer as my "go-to" for these purposes.

I disagree with what I see as being your overly complex view on measuring CPU utilization today - but I may not be getting your line of thinking on this. Make no mistake, I agree it is no longer "easy" - just look at what the CPU itself provides to "assist" with this: a running count of "cycles"... try converting *that* to fractional seconds, given little details like clocks being continuously adjusted up and down. ;)

For my own "human" purposes, I am happy to let Process Hacker perform its own computations to provide me with an overall "CPU usage", which is presented as an aggregate across cores / "logical processors", that being most useful for humans... note that while Intel actually provides some "pre-digested" numbers like (my descriptions) "current aggregate CPU %" and "recent peak usage %", I believe that Process Hacker is actually going to the trouble - based on an option I enabled - to build up utilization numbers from the raw "cycles" with the current "spot" clock rates factored in. Wow.

Oh, and, yeah - VB says it all, and absolutely speaks to your patience and perseverance. :P

Regarding your "non-technical" reasons for a closed interface, I obviously can't argue with them - they are your reasons. I consider it unfortunate (certainly for me personally), and do agree with you on it limiting what "plugins" may or may not be available to extend the amazing platform you have created.

My own take is that people that choose to "open" their platforms - and indeed some of the harder-core "Open Source" advocates - take their positions on open-ness largely out of an enlightened self-interest... for a not-that-large investment of time and resources, they are suddenly able to benefit "for free" from the efforts of scores, 100s, or 1000s of others!

Sure, this is a somewhat simplified and idealized statement of a particular position, but... and I see it as exposition, not arguing, which I said I wouldn't do. ;)

Thanks again for your response and for Winstep Nexus itself.


Back to top
 Profile  
 
Post new topic Reply to topic Board index : Winstep Forums : General Discussion  [ 3 posts ]
Display posts from previous:  Sort by  

Who is online

Users browsing this forum: No registered users and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: