Archive for August, 2007

firesync 2.0 coming soon

firesync 2.0 is just around the corner, there aren’t a whole lot of new features but it’ll be very stable and fast, with quite a few tweaks (delay in querying the network won’t lockup the UI) and improvements (graceful handling of conflicts, where copies of overwritten files are sent to the recycle bin). Perhaps the only major new feature it’ll have will be the ability to handle file deletions and renames, which seems to be an issue with a lot of sync apps. (A revised sync algorithm handles this, it’s not done using a service running in the background; I wanted to avoid a service at all costs as it can lead to some sticky situations, e.g. what happens if the service doesn’t start or is killed?)

One feature I would have liked, but may not make it in is “auto-sync,” which would have automatically sync’d files when your CPU was idle or its usage was very lower (I rejected the idea of a scheduling system b/c [a] users won’t take the time to do it and [b] it can be hard to guess when both machines setup to be sync’d would be free and connected to the network). It’s not difficult to implement, but I doubt I’ll have the time to properly test it (and for firesync, testing anything takes a huge amount of time and patience). However, it’ll definitely be in firesync 3.0.

Anyways, I’ll be talking more about firesync 2.0 when it’s released, for now, enjoy the new logo…

firesync 2.0 logo

Loop Burn

Here’s a small program I created and used to test the Single Core Launcher I talked about in my last post. It’ll run both cores in a dual-core processor at 100% (i.e. it’ll use 100% of a dual-core CPU). It might be useful to someone else.

LoopBurn -> download here!

Note: It is not generic and will not scale to processors with more than 2 cores, so this will only burn 2 cores if you have a quad core setup.

Oh, and it doesn’t do anything special it’s just incrementing variables. I was going to have it display something, but output to the console actually incurred a delay which lowered CPU/core usage.

Bad dual-core processor, no twinkie for you!

So, I’ve had a new desktop for a little over two weeks now, but stuck with my old one because there was just too much stuff that had to be transferred over or reinstalled and I didn’t have the time. This past weekend I finally made the move.

Now, my new desktop is cool high-end machine and of course that means it has a dual-core processor (well, I could have gotten a quad-core processor now, but the prices are insane). I got an Athlon 64 X2 6000+, which is pretty sweet. The comparable Intel chip (the E700 or whatever) does squeak ahead on the benchmarks, but not by a whole lot to justify its substantially higher price tag, even after the price cuts last month.

Overall I love my dual-cores, but yesterday I tried to run Deus Ex: Invisible War, just b/c I’ve never been able to run it will all the graphics setting cranked up, and it froze on the menu screen. So I rebooted (it was fullscreen, and I couldn’t get to task manager) and googled for solutions. Turns out it’s a pretty common problem, and the fixes were either:

a) Install dual-core optimizer from AMD (even though the dual-core optimizer seems interesting, my system was working fine and I wasn’t too crazy about installing additional stuff just to run this game; for the most part, I like to keep my system running the way it would for a typical user so I don’t write code with false expectations about the environment it’ll be running in.)

b) Hit Ctrl+Alt+Del before the menu screen shows up and set the thread affinity of the process to a single CPU core. (I played around with the config file, was able to start the game in a window, to prevent having to reboot if it froze again, and this little hack worked, but requires an amazing amount of speed and agility to set the thread affinity before the game loads the menu)

So the problem was obviously that the game couldn’t deal with multiple cores.

I had played around with thread affinity (just a fancy way of saying which processor a thread runs on) in code a while back and figured it might be possible for me to do a quick program to set the thread affinity automatically. The big question was would it be possible for a parent process to set the affinity of a child process, and would any processes spawned by that child process inherit the affinity? (The inheritance issue was especially important b/c DX:IW is started by running DX2.exe which executes DX2Main.exe, and you can’t execute DX2Main.exe without launching DX2.exe; there are quite a few other games that have similar setups). I guessed that affinity should be inherited and after a little bit of digging, a post in Raymond Chen’s blog confirmed my assumptions.

So, I set about making an application which would allow you to run a program on a single core of a multicore processor. It took a couple of hours. I did a nice interface using C#/Winforms and the code to actually launch the app and set the thread affinity was done in C++/Win32. I’m calling it Single Core Launcher, this app was small and simple, so no fancy name for this one.

single core launcher screenshot

Single Core Launcher -> download here!

(Extract all files to the same directory and run “Single Core Launcher.exe”; requires .NET Framework 2.0)

Oh, before making this I also found Mike Lin’s SMPSeesaw, which is pretty cool, but it only allows you to switch which core an app is running on after it’s already been started.