[conny]

I stumbled upon this great thread this morning. I haven't seen anybody else posting a reference to it. It discusses why VPC 5 is so much slower under MacOS X. Very interesting reading...

VPC 5 FAQ

[ChaChi Boy]

Ya, but in the end it is still slow. I don't get my work done any faster knowing WHY it is slow.

[juanvaldes]

Originally posted by ChaChi Boy:
<STRONG>Ya, but in the end it is still slow. I don't get my work done any faster knowing WHY it is slow.</STRONG>

but it makes you a more informed consumer. and isn't that why we come here?

[b*tchy]

Actually the response explains many of OS X's performance problems when compared to OS 9. But having said all that it is always possible to make software faster by optimizing the code... I'm sure both VPC and X will get faster over time....

[Oink]

What happens to the claim that VPC running on X burns! When they showed off speedy render in AutoCAD within VPC running on OS X at MWSF 01 I think, when TiPB was launched. Such is progress, you learn to de-believe something every day.

[xi_hyperon]

There's a post on that that thread about using the "renice" command (links to another page). I tried it, changing the priority from -1 to -16, and VPC 5 seems to peak at around 72% now. Was peaking around 60% before.

[Groovy]

It would be so easy for them to add an option for REAL TIME THREADS
so the user could click that option KNOWING VPC will use 99% of the CPU
and itunes would not work so great. Heck even throw a warning
up when they click on that option. Let the users decide since it is their
computer.

The default would be what is shipping now.


Here you have the power of OS X and they do not even use it.
no wonder it is so slow, even the window server has higher priority.

so of course VPC speed wise is gonna suck in OS X.

Games use real time threads (when they take over the whole screen)
and so does quicktime and odds are most video/audio encoding related apps.

on a DUAL box VPC should use 100% of 1 CPU and the other can run
other stuff. Of course that is not happening on my box. I can't get VPC5
to use even 80% when I'm runnning NOTHING else and I have a Dual box.

geez

[wadesworld]

Actually, I think a big part of the problem is just programmers learning how to deal with a new multitasking model.

There's been a very large discussion over the past few days on the games development mailing list, with game developers complaining that they can't get good enough performance out of OS X because they can't take over the whole machine. Apple engineers have then debunked most of their arguments and given them suggestions on how to properly work with the scheduler.

I think Connectix is probably in the same situation. Otherwise, are they really claiming that VPC can't run as fast on Window, Linux, Solaris or any other pre-emptive systems as it does on OS 9?

I'd look for VPC to get much better over time as the Connectix engineers adjust to the new model.

Wade

[moki]

Originally posted by conny:
<STRONG>I stumbled upon this great thread this morning. I haven't seen anybody else posting a reference to it. It discusses why VPC 5 is so much slower under MacOS X. Very interesting reading...

VPC 5 FAQ</STRONG>

It isn't entirely accurate that they can't make it work as fast when running "in a window" as full screen. It *is* possible to create unbuffered windows (ala Classic) under Mac OS X.

[xi_hyperon]

Has anyone else here tried the "renice" command, with any difference in performance afterward?

[edddeduck]

I believe the article mentions that they are working with Apple engineers to see what performance gains they can get by better interaction with the scheduler.

I for one prefer the pre-emtive multitasking compared to the co-op of before this is the obvious downturn but there so many upturns I think this makes up for this.

Cheers Edd

[ShyWizard]

this is just another reason why OS X sucks
and should be in the main stream yet!

[Ron Goodman]

Nonsense. OS X is different, and being able to say why can lead to more constructive criticism than the standard "OS X sucks". I agree with the above poster that for the most part, the new scheduling algorithm is better. As the system matures, these are areas where I expect to see improvement, both from the Apple engineers and the developers. I've been running it since last October and performance has steadily improved. Thanks to Connectix for bringing this up.

[Developer]

Hmm. I tried it with Vektor3, the only app I have on my computer that qualifies as compute bound (since I don't have VPC), and that reaches 90+% CPU usage while calculating a move.

[absmiths]

Originally posted by ShyWizard:
<STRONG>this is just another reason why OS X sucks
and should be in the main stream yet!</STRONG>

This is just another reason why trolls suck
and should (not) be in the forums.

[absmiths]

I think one of the posters (OpenStep) to the Connectix thread summed it up - VPC is slow because of Connectix. The scheduler might not be perfect (name one that is), but the bigger problem has already been mentioned and that is that Connectix is working with a new API on a new OS and they haven't figured it out yet. I imagine the problems that Apple has been having are not so much related to the OS X kernel, but the Carbon interface to it (and besides, many of the Apple teams are new to this stuff too). The apps Eric mentioned, iTunes, iMovie, etc, are all Carbon and use the Carbon threading/process API.

To say that compute-intensive applications can't run effectively on Unix is absurd.

[xi_hyperon]

Originally posted by ShyWizard:
<STRONG>this is just another reason why OS X sucks
and should be in the main stream yet!</STRONG>

"OS X sucks" is certainly a well thought-out and constructive observation. Did you think of that while you typed it, or did it have to incubate in your complex brain for awhile? Please share more insights and remind us of why some people's keyboards should be taken away.

As for VPC 5 and other apps which need more control of the CPU, I agree that it is a matter of time before these problems get ironed out and performance improves. As the article mentions, Apple's own engineers have run into the same problem during the development of some Apple applications, so I'm sure Apple will cooperate in sharing the workarounds.

[Groovy]

There's been a very large discussion over the past few days on the games development mailing list, with game developers complaining that they can't get good enough performance out of OS X because they can't take over the whole machine. Apple engineers have then debunked most of their arguments and given them suggestions on how to properly work with the scheduler.

Oh please how can they debunk that. If the other apps and window server
etc.. have higher priority then they will get time and your game speed will suffer.
simple as that. There is only so much CPU to go around so a game that needs
lots of CPU should be able to get it easily if it wants AND the user agrees.
Telling Devs to NOT do real time threads is crapola. It should be available
and the users should have final say to let that game (whatever app)
use real time threads and block.

It is my computer and I WANT the option to give VPC 100% and if
I go FULL SCREEN with VPC or a game then that should be a given.

If I need a web server running or iTunes then let me tell the app
to use only 80%. See my big complaint is the power to choose is being
taken away from the user via pressure from Apple on the Devs to NOT
use real time threads . Just give me the power to choose
and I will be HAPPY. Options are a good thing in this case for sure.

Now for VPC codeers what the heck are they thinking. How could they not
include this option is beyond me since it is so obvious and easy to do.
Even me a weekend coder for fun can do real time threads. The tech
notes are there as well as sample code.

Also Moki is right you can do unbuffered windows.

As you can see I'm VERY disappointed in VPC 5 as I have bought every upgrade
since 2.0 and this is the first time I feel they dropped the ball big time.

An no doing a renice -20 is not the same thing as the app doing
real time threads correctly since it seems when i try this, very quickly
VPC falls back to 0. Either VPC is doing it or the scheduler is some how
knocking it back down because VPC5 is doing something wrong
like not blocking correctly or who knows what. The main thread
the one that emulates the 86 instruction set should be real time
any other threads odds are can be left alone.

VPC 5 on OS X is NOT ready for prime.

yes the above is JUST MY HUMBLE OPINION : )

yes I will shut up now LOL

[wadesworld]

Oh please how can they debunk that. If the other apps and window server
etc.. have higher priority then they will get time and your game speed will suffer.
simple as that. There is only so much CPU to go around so a game that needs
lots of CPU should be able to get it easily if it wants AND the user agrees.
Telling Devs to NOT do real time threads is crapola. It should be available
and the users should have final say to let that game (whatever app)
use real time threads and block.

No, it's not as simple as that, as the lengthy discussion pointed out.

I'm not going to repeat the whole argument here. Go read the mac-games-dev mailing list archives if you want the gory details.

The upshot is, high performance applications ARE possible without the application needing to takeover the entire CPU.

And if you want the control over saying an app gets the vast majority of processing time - you've got it. Quit any apps you don't want to have cycles.

Wade

[wadesworld]

See my big complaint is the power to choose is being
taken away from the user via pressure from Apple on the Devs to NOT
use real time threads .

Realtime threads have a specific purpose and if they are abused, the whole system will suffer.

When a realtime thread is running, NOTHING else gets time. Not the window server, not the Carbon audio subsystem, etc.

In short, the answer is not for developers to be allowed to elevate all their threads to realtime threads. The answer is for them to better understand programming in a pre-emptive system.

Wade

[Groovy]

Realtime threads have a specific purpose and if they are abused, the whole system will suffer.

When a realtime thread is running, NOTHING else gets time. Not the window server, not the Carbon audio subsystem, etc.

first off , real time threads do NOT USE 100% of the CPU.
Where did you ever get that idea from? If you even try that
your app wil be throttled back by the OS. Also if 2 apps are both
running real time threads they SPLIT the CPU etc..... This
is when a dual box KICKS ASS : )


second.... i said the USER should be the one that decides if the app
gets most of the CPU and VPC should throw a warning up as well.
I repeat a warning to let the user know low priority apps will suffer.

The whole point you missed was this should be the users decision
not Apples. If I want VPC to use 98% of the CPU and have
itunes skip then that is on me. Give me the option at least.

Next you will be teliing me it woul dgo for Apple to remove nice/renice
from system so users and change priorities at all. Geez i hope not

Right now I can't get VPC 5 to go past 80% with NOTHING ELSE RUNNING
and I reniced VPC to -20 and every number down to 0 to see what would
happen.

If VPC had the option for real time threads I could get VPC to 95%.
5% is plenty for the rest of the system because I'm not RUNNING
anything else when I run VPC.

ok?

[Groovy]

No, it's not as simple as that, as the lengthy discussion pointed out.

I'm not going to repeat the whole argument here. Go read the mac-games-dev mailing list archives if you want the gory details.

The upshot is, high performance applications ARE possible without the application needing to takeover the entire CPU.

And if you want the control over saying an app gets the vast majority of processing time - you've got it. Quit any apps you don't want to have cycles.

Wade

Ok I did and I was right. There is no reason not to use real time threads
when done correctly and the user is given given a warning that their others apps
will suffer. the dev list actually proved me right in that real time threads are THERE
to be ****used**** but **** not abused**** and can't be abused
since your app will be put in the pentality box if you tey to use 100% CPU.

No one said anywhere that an app can get 95+% cpu while other apps
are running with the same priority or higher than the game. Why?
because it is not possible. so you are incorrect when you said above
"The upshot is, high performance applications ARE possible without the
application needing to takeover the entire CPU." They all claim it
can be done IF you are running ONLY that app. Which is what I said already.

Now what is worse even is this....
I said days ago I can't get VPC above 80% running ALL BY ITSELF
so you bring up the quit all apps stuff but that is what I told you I tried days ago.
That was the first thing i tried. Then I went to renice. this is VERY BAD
and either VPC is doing something really wrong or OS X
is not as good as many think. At least 15% more should be going to
VPC5 since 5% is plenty for everything else (since I'm not running anything else
and interupts and other low level tasks should not need more than 5%)

also this thread is about VPC and out of all the apps out there
this is one app that should give the user an option to use real time threads.

Note: i said option, not force real time threads. Let the user decide.
Put the power in our hands please and do not take our renice away ; )

[michaelb]

15% performance hit, eh?

So I guess moving from, say, a G4/450 MHz to a G4/500 MHz should just about compensate!

Maybe we should all just visit www.xlr8yourmac.com and learn to overclock our CPUs a bit...

Just being whimsical!

[theolein]

Originally posted by moki:
<STRONG>

It isn't entirely accurate that they can't make it work as fast when running "in a window" as full screen. It *is* possible to create unbuffered windows (ala Classic) under Mac OS X.</STRONG>

Do they have to be written in the application, or is it something that can be changed in run time?

[wadesworld]

Originally posted by Groovy:


Ok I did and I was right. There is no reason not to use real time threads
when done correctly and the user is given given a warning that their others apps
will suffer. the dev list actually proved me right in that real time threads are THERE
to be ****used**** but **** not abused**** and can't be abused
since your app will be put in the pentality box if you tey to use 100% CPU.

I don't know how you consider yourself right. In fact, I'm not sure you were even reading the same thread.

I guess you saw the parts where Ian, Geoff and George were urging the developers to be very cautious with any use of realtime threads because they're very rarely necessary?

You're correct that apps that try to consume 100% of the CPU will get penalized. Why? Because the OS would stop working. Things which use realtime threads should do their work quickly and then block. That's a far cry from running your application's loop in a realtime thread.

Here's a few quotes:

Ian Olmann: As I said before, even if you are prioritized down to
weightless, you can still get 90-95% of the CPU if there aren't any
other busy apps competing for time.

Ian Olmann: Question: Is this *really* necessary? When you are at that priority, you
are actually at a higher priority that some other things that I think
you would rather be at higher priority than you are. You dont want to
elevate yourself higher than the DeferredTask thread, for example. This may have significant adverse effects on Carbon audio playback.

Geoff Stahl:

A little knowledge is a dangerous thing, a lot of knowledge is much
safer. If you do not completely understand threads, blocking,
priorities, scheduling, and pre-emptive multi-tasking systems then DO
NOT use real time threads. Bottom line, understand what you are
doing before you do it. Just setting your app to real time priority
may have problematic consequences and in the end may not give you
what you want.

I stand by John Stiles remarks. If you have not looked at QA 1061
and have not tried Carbon Events then do so before considering
adjusting your priority. We have lots of apps that have very
demanding requirements that do not need to be real time priority.

No one said anywhere that an app can get 95+% cpu while other apps
are running with the same priority or higher than the game. Why?
because it is not possible. so you are incorrect when you said above
"The upshot is, high performance applications ARE possible without the
application needing to takeover the entire CPU." They all claim it
can be done IF you are running ONLY that app. Which is what I said already.

Game developer John Stiles:
&gt;My personal preference has been to adopt a slightly modified version of
&gt;the event loop code in TN1061
&gt;(http://developer.apple.com/qa/qa2001/qa1061.html). This code can easily
&gt;be adapted to work with almost any game loop. Using this has given our
&gt;app very close to 100% of the CPU--in fact, over 110% on MP machines,
&gt;where OpenGL, sound mixing and other tasks can run on CPU 2.

Now what is worse even is this....
I said days ago I can't get VPC above 80% running ALL BY ITSELF
so you bring up the quit all apps stuff but that is what I told you I tried days ago.
That was the first thing i tried. Then I went to renice. this is VERY BAD
and either VPC is doing something really wrong or OS X
is not as good as many think.

Why is it that VPC cannot run well, but a resource-intensive game like Return to Castle Wolfenstein can?

Note: i said option, not force real time threads. Let the user decide.
Put the power in our hands please and do not take our renice away ; )

What's the difference between setting a preference that says "Steal all CPU time" and quitting apps that you know would be competing for time?

Wade

[Developer]

Originally posted by wadesworld:

What's the difference between setting a preference that says "Steal all CPU time" and quitting apps that you know would be competing for time?

Yeah, I don't understand that either. If he wants VPC to use that much CPU time to make iTunes skip, why not simply pause iTunes?

[graffix]

Hrm... there seems to be a bit of confusion about this, so I'll see if I can sort-of explain what's happening to apps behind the scenes (in the limited way I understand it).
The reason VPC runs slow, is because it's a 'user-space' application. All user-space applications start out with a 'nice' (priority) of '0' (even the WindowServer, contrary to popular belief... if you 'renice' the windowserver, the old priority was '0'). It's impossible (without gaining root access) for an application to 'renice' itself to a higher priority (a'la lower than 0, like -1 through -20).
Now for the second half of the problem. The Mach Microkernel has it's own dynamic scheduler that allocates processor time based on priority, but in the event that an application tries to suck up too many CPU cycles (a'la Virtual PC and other 'compute bound') applications, the Mach scheduler re-prioritizes the threads so they are lower priority to keep them from hogging all the CPU cycles.
Up until now, Connectix believed the 'renice' command was broken (due to Mach's dynamic scheduler), but it was brought to their attention over in their forums that it still functioned correctly, which prompted them to open talks with Apple Engineers (as per the FAQ).
I've 'reniced' VPC, and the gains are dramatic.
The secret is not to assign it to the priority of a 'real-time' thread, or it'll get penalized by the microkernel. I usually use a priority of -10 for VPC, which gives it plenty of priority without overly penalizing it in the process.

For anybody who doesn't know how to 'renice' an application, here's how to do it.
1. Launch VPC (duh ).
2. Launch the terminal application
3. 'su' to the root account (if you have no root account, you can activate the root account through the NetInfo Manager (which I wont' get into here... there's plenty of places around the web that tell you how)).
4. Type 'top' at the command prompt, which will bring up the list of running applications with their process ID (pid) numbers, among other system info.
5. Take note of Virtual PC's PID #.
6. Type 'command-.' to exit top
7. Now type 'renice &lt;priority&gt; &lt;VPC's PID&gt;'
For example, if Virtual PC's pid was 391, and you wanted to use a priority of -10, the command would read: renice -10 391
8. The terminal will affirm the command by echoing the new and old priorities.
9. Now go back to VPC and enjoy the speed gain (not as dramatic as switching back to OS9.x to run it, but impressive nonetheless).

Here's my speed tricks for VPC with Windows2000.

1. Give VPC as much ram as it wants (I give it 224MB out the 384MB I have in my iBook).

2. If you are running it on a portable Mac, download APM Tuner X (it's available at versiontracker), and set the hard drive APM to MAX (never sleep).

3. Create a fixed-size drive image between 256-512MB to use as a 'swap' volume (since VPC now allows connecting 3 HD's this works quite well). Once you create the drive, restart the PC, control-click on the 'My Computer' icon, then select 'Properties'. Now, find the pane that allows you to change the VM settings (not sure exactly the name at the moment), and remap VM to the drive you just created (I actually formatted the new drive as NTFS within Win2K before this).

4. Turn off all unnecessary system options (such as personalized menus, menu animations, etc.)

5. Download 'Tweak UI', a UI tweaker from MicroSoft (you can download it from Download.com's PC site). This allows you to change the delay in menus popping open, etc., which helps the overall 'feel' of the OS.

6. Use the 'renice' command I mentioned above.

All these things combined really gave VPC a nicer feel, though it's still not as fast as a real PC (obviously ).
I'm sure given time Connectix engineers will figure out ways around OSX to give VPC back most of the speed we were used to under the 9.x line of OS's.
Just cut'em a break, because they're not 'shoddy' engineers (as some people are intimating).
[edit] I should add that I'm using a 2001 iBook Dual USB 500Mhz (the original, ordered on May 2nd ).
g.

[ 12-23-2001: Message edited by: graffix ]

[Developer]

1.) renicing to -20 is not the same as a real time thread
2.) renicing to -20 does absolutely nothing with only one application running
3.) an app with priority 0 can easily get 90+% CPU time when running alone without being penalized by the scheduler
4.) real time threads are by no means intended to run your main application thread
5.) if VPC can't get more than 80% CPU time when running alone it's VPC's problem not a problem of the scheduler (what is eating the other 20%?)

[moki]

It is definitely true that good performance can be gotten out of Mac OS X without jacking your thread into the realtime band. Most of the reason for apps not performing well under Mac OS X is because developers are still learning what to do.

Mac OS X is a very different system than the classic Mac OS, and many developers coming from that background are carrying with them the baggage from Mac OS 8/9. What worked well under "classic" Mac OS does not work under Mac OS X. I'm not just talking about specific APIs, but also overall tenents and methods.

Yes, you can port something to Carbon quite quickly. What you can't do quickly is learn all of the nuances, tricks, and knowledge that you need to make an app that performs well. Many developers haven't made that transition yet.

Don't accept as a given that an app should perform poorly under Mac OS X -- it shouldn't. Blaming Mac OS X for an app being slow isn't fair; it is very possible to make an application perform well under Mac OS X. It just takes some time.

[Groovy]

It is definitely true that good performance can be gotten out of Mac OS X without jacking your thread into the realtime band. Most of the reason for apps not performing well under Mac OS X is because developers are still learning what to do.

Moki - your above statement is only a half truth.

There is a reason WHY there are real time threads.
Some apps need more CPU even when written correctly. simple as that.

Quicktime is one such beast. Even more so when playing movies and the player
is the foreground app. The user is telling the OS it wants QUICKTIME
to get priority when an app is in the foreground. QUICKTIME is smart enough
to give up CPU when it's player window is covered by other windows.
Good coding since no need for real time when the user can't see the window
but it keeps playing time wise so when you do uncover it 1 minute later
then 1 minute of the movie has played. (This could be an option
i.e. pause in background. heck it might be already I need to look but
I'm in OS 9 right now)

You can write the perfect game with perfect threading code and it will not
help much if I'm running other apps with perfect threading code as well.
Your game will run slow unless i quit the other apps like iTunes for an example.

Now which is better

1) your game taking over the whole screen and using real time threads
*which i told it to do* and I do not have to quit all my apps every time i want
to play your game

or

2) I'm stuck quitting all apps first every time I play your game to get good FPS
because apps like office eat 20% of CPU even when in the background
doing crazy auto type spell checking and are at the same priority level as your game
threads.

It is a game in full screen mode so .....
Like i said give the user the option to use a real time threads
then the user will not have to quit out of everything to get decent speed
and the game will not stutter if Office goes insane and starts eating 50%
cpu to do some nonsense or Norton kicks in to do a volume check or whatever.

I see no problem with putting control into the users hands and warning them
when they click on the real time option check box that other apps will get
less CPU.

now this brings me back to VPC 5. quitting all apps does not help so something
is really wrong here. I did a top and saw VPC 5 at 73% top at 4% and
window server at 2% and that was it and I was running a mpg in media
player in Win 2000 Pro to make sure VPC 5 was working hard. (Getting
like 3 FPS LOL ) My idle_thread was hovering around 20% yuck ; )

[moki]

Originally posted by Groovy:
<STRONG>There is a reason WHY there are real time threads.
Some apps need more CPU even when written correctly. simple as that. </STRONG>

Well, sure -- we use a realtime thread in Snapz Pro X as well. I never said there was no use for them, but rather that just jacking your thread into the realtime band isn't a good solution for performance problems.

[wadesworld]

1) your game taking over the whole screen and using real time threads
*which i told it to do* and I do not have to quit all my apps every time i want
to play your game

or

2) I'm stuck quitting all apps first every time I play your game to get good FPS
because apps like office eat 20% of CPU even when in the background
doing crazy auto type spell checking and are at the same priority level as your game
threads.

I fail to see the huge difference between the two.

But regardless, apps in the background should not be taking 20% of the CPU unless they're doing something. If Word is in the background, it should be taking up absolutely zero cycles, or close to it. If it does take up time, it's not programmed correctly. Therefore you should quit it.

I see no problem with putting control into the users hands and warning them
when they click on the real time option check box that other apps will get
less CPU.

Once again: realtime threads are not used to run an application's main event loop. A realtime thread should do what it needs to do very quickly and then block.

You can have as many applications open as you want. As long as they are programmed correctly, they won't take up CPU time when in the background, unless they're designed to take up time in the background (such as a web server).

I can think of all sorts of problems with your scenario. What if programmers start using realtime threads and suddenly start affecting the network stack because the network stack can't get enough time?

What if I want to Command-Tab out of my game but I can't because the window server can't get enough time because the game uses huge realtime threads?

What if I like to listen to iTunes in the background while I play my games, but all of a sudden it doesn't work with most games because so many programmers started using realtime threads?

What if programmers take away the choice to make a realtime thread an option because they found if they just threw in a realtime thread, everything worked, so they got lazy and shipped the game without doing the work to figure out how to make the game run well without realtime threads?

On the other hand, maybe it's not so dire. If programmers start trying to use realtime threads and abuse them, the scheduler will punish them and then the game's performance will truly suck.

In short, the answer is for programmers to learn how to work in a pre-emptive system, not give them a quick hack to make it easy to be like the OS 9 days.

Wade