Zugg Software :: View topic

Posted: Tue Aug 07, 2007 4:21 pm

Since I've started dealing with the dual core machines a puzzling thing keeps coming up. I see many apps that simply "max out" at 50% usage. At first glance you would think it's just a single thread process maxing out one core. Here is where it gets bizarre when you go into Task Manager and check the individual core usage. One core will be at 80% and the other at 20%.

Cmud does the same exact thing. Easy test. Just do an Ctl-Q 5 times real fast while you have task manager open. I was really disappointed when I found out that this lovely brand new app was barely faster on the dual core machine than a single.

The closest explanation I have come up with is this http://www.shareware-beach.com/2005/10/a-new-era-of-computing/.

I'm really hoping that 2.0 will perhaps fix this. Althought I've noted that the source machine is apparently an older single core box. I'm guessing it's a similar issue as this perfectly describes what I witness.

I also suspect that this may be a source of several bugs. As I have far more problems with Cmud on my new dual core machine than any of the older single core machines. Which makes sense as it is entirely possible for 2 things to happen at once now.

Wanderer Joined: 09 Jun 2006 Posts: 62 Location: Florida

Honestly, this is nothing new. Any program can benefit from being run on a computer with more than one core, but the fact is... it takes a lot of forethought to have a program specifically designed to handle more than one core / more than one CPU possibly such that the lode is shared equally between the two of them. You'll note if you use any amount of programs and/or games, your dual-core CPU will very, very rarely have equal CPU usage except when they're both pinging at 100% or near it. I'd suggest getting a powertoy of some kind, or, if you're using Vista, getting a sidebar gadget to show you the % of each CPU that's being utilized.

Just because the cores aren't being utilized equally does not mean the app is in any way flawed, broken, evil, error-prone, etc. For example, I've personally had fewer issues with CMud on my dual core box than I had running it on a single core box. That doesn't mean having dual cores "fixed" any problems for me, it simply means any potential problem is likely unrelated to number of cores anyway :)

Edit: Just to expound a bit on my first statement: Running dual cores is somewhat akin to having multiple CPUs. Loop unrolling and other techniques are used to try to modularize the code to a point where there are no real code dependencies, which means that the code can be run simultaneously on more than one CPU and/or core and then the results can be merged afterward. For things like loops that are independent, this can be invaluable.

However, consider the implementation scenario here: CMud basically has to check every trigger to see if it matches each line or blurb of text being received from the MUD. There aren't many ways you can have an independent data source that can speak to more than one possible thread and maintain concurrency in such a way that it'd honestly satisfy the developer or, in this case, multiple CPUs.

Posted: Tue Aug 07, 2007 5:29 pm

My point I was making. Cmud is the going into the future application. The future for the time being is going to be increasing number of cores with slight increases in IPC per cpu. At some point I would hope that the capability to break out the chores more robustly would be implemented.

As for the triggers. It seems like an almost ideal chance to break out the work. Network job handler takes the incoing lines, hands them off ( mailbox? ) to a thread bank with each thread having several of the triggers. The results could then post back to a scheduler who passes it off to updating the packages and another who is in charge of drawing the screen.

Yes I don't expect both cores to all hit 100%. There is obviously oppurtunity though to get more out of the program. If one core only ever hits 80% and the other 20%, what is holding back from hitting 100% on one of them. Could perhaps the 80% be split up such that we hit 90% and 50% allowing the work to be spread out. If you read the article linked the programmer had a situation where he was thread-safe but not really thread efficient.

If this ends up eating more memory then so what. Most Vista installs are going to have 1Gb+, more likely 2-3Gb and Cmud as it currently stand really does not use much memory. Another meg or two doesn't really matter to me. I keep wondering why Zugg is trying so hard to keep one data cache with multiple sessions. Myself I'd go for a new cache for each session and implement a database scheme to track updates to the files similar to the MS active directory implementation for updates.

Posted: Tue Aug 07, 2007 5:37 pm

The 2.0 version of CMUD might handle multiple cores better since the new version is multi-threaded. Windows *should* detect this and allow the threads to run in different cores, but it will be up to you to tell CMUD to run the threads in parallel and to handle any data locking or synchronization that might be needed.

CMUD (and zMUD) normally execute triggers sequentially. It waits until one trigger is finished processing before testing any further triggers. This design is on purpose since many people rely upon sequential execution in their complex scripts. Running triggers at the same time in multiple threads can cause all sorts of problems (as with any multithreaded application). You can look around this forum for our recent discussion about the threading in v2.0 and all of the complexity that it involves.

The reason CMUD has a single internal cache for multiple sessions is that many people often want their sessions to interact. The sessions are sharing a single GUI, and anything related to the GUI has to be synchronized with the main application thread. Also, CMUD has the concept of "shared packages" where multiple sessions share a single copy of another package, and that requires a single memory cache.

You can speculate about this stuff, but I've been doing this for a long time and worked several years on the rewrite for CMUD and the new design. As Arlie mentioned, making full use of multiple processors is very non-trivial. CMUD already uses background threads for database updates and stuff like that. There is very little else that can be handled in parallel. The 2.0 version will let you do more of this, but my guess is that you'll run into more data locking and synchronization problems then you'll want to deal with.

Wizard Joined: 14 Aug 2004 Posts: 1269

This may well already be the case, but the GUI widgets use CPU to render (e.g. when you open the package editor) and some of them when you hover the mouse over them, so this can be in a different thread to the trigger processor, can't it? Possibly speeding up opening the package editor or similar GUI tasks. I suppose when scripts are running though, they can affect the data that should be displayed in the package editor, and this might cause problems. But there are other dialogs that are unaffected by scripts (like Preferences, maybe). Anyway, just some musings.