Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (482)
Games in Android Showcase (110)
games submitted by our members
Games in WIP (548)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Threads and wait()  (Read 1654 times)
0 Members and 1 Guest are viewing this topic.
Offline barfy

Junior Member




The evidence of things not seen


« Posted 2004-09-08 10:10:42 »

I'm using a multi-threaded SoundManager class (which extends ThreadGroup by the way) for sound playback using the javax.sound API. Basically, how it works is that each initialized Thread will wait() on that SoundManager object until there is a task (sound) ready to be executed and than a random Thread will be notify()ied to execute the task.

It's all good except that I'm getting a surprisingly big performance hit, even when there are no sounds playing, which implies that all sound playback Threads are wait()ing on the object. So I'm guessing it's not the javax.sound API's fault.

I'm using up to 16 sound playback Threads btw. Just to clarify, should there be a performance overhead even when all these Threads are wait()ing?
Offline barfy

Junior Member




The evidence of things not seen


« Reply #1 - Posted 2004-09-08 14:30:31 »

Ran a profiler and found out that a native mixer thread (probably initialized by the javax.sound API) is taking up 22% of the execution time (as compared to 77% for my main thread). Horrible. And it looks like it's still doing SOMETHING even when no sound is being played and all my sound playback Threads are wait()ing. Why?
Offline dranonymous

Junior Member




Hoping to become a Java Titan someday!


« Reply #2 - Posted 2004-09-08 18:11:33 »

Which profiler are you using?

Have you tried profiling a program that just loads an audio clip but doesn't play it?

Regards,
Dr. A>
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline barfy

Junior Member




The evidence of things not seen


« Reply #3 - Posted 2004-09-09 01:02:51 »



JProfiler shows that the MixerThread is spending 14.1% of the time calling Thread.sleep() (which incurs a small overhead in itself from all that context switching) and another 7% of the processor time doing god-knows-what. And this is when NO SOUNDS ARE ACTUALLY PLAYING EVER, although there are multiple SourceDataLines open()ed and start()ed. No data is sent down the lines at anytime.




Offline crystalsquid

Junior Member




... Boing ...


« Reply #4 - Posted 2004-09-09 07:22:42 »

It depends on what the other threads are doing. If this is a small test bed for just sounds so the main thread is not actually doing much, then the (low) overhead of the threads will appear as a significant fraction of the time.

For example:
Thread switching take 2 ms for all the sound threads.
Main thread yields once a frame.
In a testbed we are running 100 fps.
I would expect the sound threads to be activated every 10ms. They take 2ms, giving 20% on a profile.

Example 2, a game frame takes 40ms (25fps) with one yield per frame. The thread switching in the sound still takes 2ms.
The thread switching in the sound now accounts for 5% on a profiler.

Ok, so thread switching is usually not that simple, but my point is we need more info before any conclusions on performance can be drawn - except the standard mantra of micro-benchmarking (& micro-profiling) can be tricky to interpret correctly.

- Dom
Offline barfy

Junior Member




The evidence of things not seen


« Reply #5 - Posted 2004-09-09 10:28:12 »

Quote
It depends on what the other threads are doing. If this is a small test bed for just sounds so the main thread is not actually doing much, then the (low) overhead of the threads will appear as a significant fraction of the time.


I'm running a reasonably sized application/game so we can safely assume that the main thread IS doing quite a bit of work with game logic processing and rendering per frame.

Quote

For example:
Thread switching take 2 ms for all the sound threads.


We are only talking about 1 native mixer Thread here that is initialized by the Java sound API.

The other sound playback threads are all wait()ing on an object so they aren't doing anything and aren't in the equation actually.

Quote

Main thread yields once a frame.
In a testbed we are running 100 fps.
I would expect the sound threads to be activated every 10ms. They take 2ms, giving 20% on a profile.


So that's lousy isn't it?! That's 20% of your processor time doing nothing but context switching...

Remember - there are 2 seperate Threads of execution here, 1 native mixer thread and the main thread. So the percentage we're talking about (in order for it to make sense and that JProfiler is showing) is in terms of CPU slice time... Correct?

Then again, if the percentage in JProfiler is talking in terms of CPU slices, and if Thread.sleep() isn't supposed to be taking up processor cycles while sleeping, why is it showing that it's taking up a good 14% in the profiler?

Damn it's late and I'm getting a little confused...

In actuality, I'm more interested in the other 7% of CPU time that the native mixer thread is using up doing something naughty when it's not sleeping and no sound playback is happening. Looks like a waste of precious CPU cycles to me.

Some feedback and suggestions would be very appreciated. Thanks  :-/
Offline cweila2s

Senior Newbie




Java games rock!


« Reply #6 - Posted 2004-09-09 13:33:09 »

I don't know which behavior the process scheduler in Windows XP uses, but why don't you try and give them a amount of time when sending them to bed -> wait(100). Sounds (haha) not very reasonable, but I'd be interested in the results.

Another thing is - why do you want to have one thread for each sound??? Of course the scheduler has to look after its threads, so why don't you make its work easier and give it only on thread at all? What about a thread-free solution? Depends on what kind of application you use that for, of course...

If I understand you right, even an uninitialized sound schedular take process time? That'd be very bad  Sad
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

atombrot (27 views)
2014-08-19 09:29:53

Tekkerue (25 views)
2014-08-16 06:45:27

Tekkerue (23 views)
2014-08-16 06:22:17

Tekkerue (15 views)
2014-08-16 06:20:21

Tekkerue (22 views)
2014-08-16 06:12:11

Rayexar (61 views)
2014-08-11 02:49:23

BurntPizza (39 views)
2014-08-09 21:09:32

BurntPizza (31 views)
2014-08-08 02:01:56

Norakomi (37 views)
2014-08-06 19:49:38

BurntPizza (67 views)
2014-08-03 02:57:17
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!