| Author |
Message |
Slinky
Joined: Jan 09, 2009
Posts: 15
Location: Sweden
|
 Posted: Fri Jan 09, 2009 12:59 pm Post subject:
Insane CPU usage |
  |
|
Hello!
I use Chuck 1.2.1.2 (dracula) with Jack, under Linux. Running e.g. examples/deep/thx.ck causes huge CPU usage, Jack DSP usage count maxes out and there are a lot of xruns. I can't really hear the sound properly.
Tried --bufsize with different values, also --bufnum, but no help.
Resonz.ck lifts "DSP usage" of Jack up to about 30%.
I don't think the CPU usage should be so insane - does anyone have clues what I'm doing wrong? Or tips what to do or change?
Jack setup works OK otherwise, my laptop is 1.6 GHz AMD.
(I also tried to pinpoint the problem with Valgrind's callgrind tool, but all it showed was large amounts of call to Chuck_VM_Shreduler::advance and Chuck_UGen::system_tick, which I think are somehow normal.) |
|
|
Back to top
|
|
 |
radarsat1
Joined: Mar 14, 2008
Posts: 85
Location: Montreal
|
| Posted: Fri Jan 09, 2009 2:52 pm Post subject:
|
|
|
| thx.ck runs 30 oscillators through two reverbs and steps 10 samples at a time. sure, it uses CPU. |
|
|
Back to top
|
|
|
Inventor
Stream Operator
Joined: Oct 13, 2007
Posts: 6221
Location: near Austin, Tx, USA
Audio files: 270
|
| Posted: Fri Jan 09, 2009 5:36 pm Post subject:
|
|
|
| radarsat1 wrote: | | thx.ck runs 30 oscillators through two reverbs and steps 10 samples at a time. sure, it uses CPU. |
That IS insane! Haha!
_________________
"Let's make noise for peace." - Kijjaz |
|
|
Back to top
|
|
|
Slinky
Joined: Jan 09, 2009
Posts: 15
Location: Sweden
|
| Posted: Sat Jan 10, 2009 3:24 am Post subject:
|
|
|
| radarsat1 wrote: | | thx.ck runs 30 oscillators through two reverbs and steps 10 samples at a time. sure, it uses CPU. |
So do I interpret you correct that it is normal behaviour? My environment is not broken? If so, then fine, I'll just have to adapt to that.
Is there anything I could do to tune the performance, any tips?
I don't care about latency but at least I'd like to hear stuff without dropouts.
(Even 30 oscs + 2xreverb. I remember Buzz ran OK with that sort of stuff on a 400 MHz Pentium back in the days. Maybe time goldens memories or something.) |
|
|
Back to top
|
|
|
Inventor
Stream Operator
Joined: Oct 13, 2007
Posts: 6221
Location: near Austin, Tx, USA
Audio files: 270
|
| Posted: Sat Jan 10, 2009 3:32 am Post subject:
|
|
|
From what I understand, the emphasis on ChucK was strong timing and live coding and stuff like that, with performance left as a secondary concern. ChucK is not the most efficient language by far. Try some other examples to see if your cpu is not burdened by them, I guess.
_________________
"Let's make noise for peace." - Kijjaz |
|
|
Back to top
|
|
|
Slinky
Joined: Jan 09, 2009
Posts: 15
Location: Sweden
|
| Posted: Sat Jan 10, 2009 4:07 am Post subject:
|
|
|
| Inventor wrote: | | From what I understand, the emphasis on ChucK was strong timing and live coding and stuff like that, with performance left as a secondary concern. ChucK is not the most efficient language by far. Try some other examples to see if your cpu is not burdened by them, I guess. |
Thank you! Most of the other examples played OK, although the DSP usage was quite high still. But no dropouts.
Is there an option in ChucK to instead of sample-accurate operation to use block-accurate (where blocksize is configurable) operation? |
|
|
Back to top
|
|
|
Kassen
Janitor
Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3
|
| Posted: Sat Jan 10, 2009 11:37 am Post subject:
|
|
|
| Slinky wrote: |
Is there an option in ChucK to instead of sample-accurate operation to use block-accurate (where blocksize is configurable) operation? |
No, and I think ChucK will always stay "strongly timed". In fact ChucK is several orders of magnitude more accurate than just to the sample, at least internally (IO is still affected by the blocks)
However, a version of block processing is being worked on, one that should give us block processing where this can be done without penalty to the sound quality (this is very important where feedback is concerned) and regular processing elsewhere.
This should save a lot of CPU in cases like this one, once it's done. I heard this is being worked on but I have no timetable for when it will arrive. Personally I think garbage collection is more important as more things depends on that.
_________________
Kassen |
|
|
Back to top
|
|
|
DrJustice
Joined: Sep 13, 2004
Posts: 2112
Location: Morokulien
Audio files: 4
|
| Posted: Sat Jan 10, 2009 8:49 pm Post subject:
|
|
|
| radarsat1 wrote: | | thx.ck runs 30 oscillators through two reverbs and steps 10 samples at a time. sure, it uses CPU. |
Just out of interest, what kind of oscillators are used by thx.ck? Must be very HQ to consume so much CPU, unless the reverbs are very extreme...(?)
DJ
-- |
|
|
Back to top
|
|
|
rogan
Joined: Dec 16, 2007
Posts: 83
Location: Urbana, IL
Audio files: 5
|
|
|
Back to top
|
|
|
kijjaz
Joined: Sep 20, 2004
Posts: 765
Location: bangkok, thailand
Audio files: 4
|
| Posted: Sun Jan 11, 2009 2:36 am Post subject:
|
|
|
| I might try to increase Jack's latency and see if it helps the CPU a bit. |
|
|
Back to top
|
|
|
radarsat1
Joined: Mar 14, 2008
Posts: 85
Location: Montreal
|
| Posted: Sun Jan 11, 2009 4:45 pm Post subject:
|
|
|
Witness this beauty from ugen_osc.cpp (line 416):
| Code: | | *out = (SAMPLE) ::sin( d->phase * TWO_PI ); |
That's right, it calls sin() on every sample. Most programs (Pd for example) usually use a linearly interpolated pre-computed wave table for efficiency.
Anyone want to submit a patch? ;-) |
|
|
Back to top
|
|
|
Stochastic
Joined: Feb 25, 2008
Posts: 45
Location: Vancouver
|
| Posted: Sun Jan 11, 2009 4:56 pm Post subject:
|
|
|
One thing I noticed was that running chuck in Ubuntu caused a huge CPU usage rate, but on my 64studio (32-bit) install the CPU usage decreased significantly. Has anyone else experienced this behavior or am I imagining things?
What linux environment are you in?
_________________
http://greyrock.blogspot.com |
|
|
Back to top
|
|
|
radarsat1
Joined: Mar 14, 2008
Posts: 85
Location: Montreal
|
| Posted: Sun Jan 11, 2009 5:13 pm Post subject:
|
|
|
| Quote: |
No, and I think ChucK will always stay "strongly timed". In fact ChucK is several orders of magnitude more accurate than just to the sample |
What does that actually mean, "more accurate than just to the sample"?
From what i understand the reason ChucK is called sample-accurate is because any block of ChucK code has the opportunity to run at each sample. And the whole block will run, up to the point where it advances time, before the next sample is processed.
It's really a beautiful idea in terms of audio programming, imho. But it does mean that everything you do in ChucK runs inside the audio I/O callback, so you can't get away with tons of processing all in one shot without advancing time. If you advance time by large steps usually CPU usage isn't too big a deal, but the VM _will_ still step through every Shred to check if anything needs to be called.
I think the idea of "block processing" in ChucK is that, currently, each UGen has a tick() function which returns the next sample. This is called for each UGen on each sample. This number of function calls for every single sample can start to add up due to stack operations. So if the tick() functions are modified to operate over a vector of samples, (like it usually is in most audio software), a whole bunch of samples can be calculated at once. If the amount of time to wait is known, then a bunch of blocks can be processed in one shot while waiting for the next piece of code to run.
So, while what I posted above about sin() relates to SinOsc, thx.ck uses SawOsc.which should be quite a bit better. The code is just a few multiplies, compares, and adds. Perhaps it's just a little too much logic to be efficient, but I think the single-sample tick() function calls are probably the real drain.
I think to determine the real CPU hog in thx you'd need to start removing things one at a time. Replace SawOsc with Step, remove the modulation, remove the reverbs, and watch how CPU usage changes.
But really to do it proper, a run-time profiler could tell a lot of information about how much time ChucK spends inside each function, and how much time is used manipulating stack between function calls, etc. |
|
|
Back to top
|
|
|
Slinky
Joined: Jan 09, 2009
Posts: 15
Location: Sweden
|
| Posted: Mon Jan 12, 2009 3:09 am Post subject:
|
|
|
| Stochastic wrote: | One thing I noticed was that running chuck in Ubuntu caused a huge CPU usage rate, but on my 64studio (32-bit) install the CPU usage decreased significantly. Has anyone else experienced this behavior or am I imagining things?
What linux environment are you in? |
I have Debian unstable/testing running in 32-bit mode.
After I pumped up Jack latency to like 137 ms, I get far less dropouts, but still get some. Nevertheless now I'm almost able to hear the whole thx.ck.
Noticed that I don't have RT-patch in my kernel - I thought I did. Guess it's time to upgrade...
_________________
"Mortal immortals, immortal mortals, living their death and dying their life."
--Heraclitus, Fragment 62, Hippolytus Ref. Ix, 10,6 |
|
|
Back to top
|
|
|
kijjaz
Joined: Sep 20, 2004
Posts: 765
Location: bangkok, thailand
Audio files: 4
|
| Posted: Mon Jan 12, 2009 7:46 am Post subject:
|
|
|
Oh.. so i guess increasing CPU power will help a lot..
or maybe try running in console mode
(no graphics)
hahahah -_- that'd help.
or for graphics, use a faster & more compact Window Manager..
let's say.. hmm..
icewm, fluxbox, .. etc. |
|
|
Back to top
|
|
|
Kassen
Janitor
Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3
|
| Posted: Mon Jan 12, 2009 8:25 am Post subject:
|
|
|
| radarsat1 wrote: | | Quote: |
No, and I think ChucK will always stay "strongly timed". In fact ChucK is several orders of magnitude more accurate than just to the sample |
What does that actually mean, "more accurate than just to the sample"? |
I mean that you can reason about moments between samples. This is important for execution order and also means rounding errors in when events actually take effect (so affect the sound) won't carry. or, to put it bluntly;
.5::samp => dur short_time; //this is valid
| Quote: | From what i understand the reason ChucK is called sample-accurate is because any block of ChucK code has the opportunity to run at each sample. And the whole block will run, up to the point where it advances time, before the next sample is processed.
|
Yes, that's right, but the block might also run twice per sample or it might run once every pi samples, in that last case the effects of the block of code may be quantised to the sample rate (or to block size, in the case of MIDI out) but this rounding error won't carry beyond how the double-float format may have very, very slight rounding errors. One example of where this may be relevant is in writing a square-wave oscillator in ChucK doing something like;
| Code: | Step s => dac;
true => s.next;
second / Std.mtof(64) => dur period;
while(1)
{
period => now;
-1 * s.last() => s.next;
}
|
Here the flanks of the waves will get quantised to the sample-rate but this won't carry so we do get some jitter but we don't get a tuning error.
| Code: | It's really a beautiful idea in terms of audio programming, imho. But it does mean that everything you do in ChucK runs inside the audio I/O callback, so you can't get away with tons of processing all in one shot without advancing time. If you advance time by large steps usually CPU usage isn't too big a deal, but the VM _will_ still step through every Shred to check if anything needs to be called.
|
Actually, I think that when shreds advance time they are put on the shreduler list and only that list needs to be checked, at least that's what teh doc's seem to imply. That does conflict with even empty shreds shreduled for some time in the far future taking some cpu.
| Quote: |
I think the idea of "block processing" in ChucK is that, currently, each UGen has a tick() function which returns the next sample. This is called for each UGen on each sample. This number of function calls for every single sample can start to add up due to stack operations. So if the tick() functions are modified to operate over a vector of samples, (like it usually is in most audio software), a whole bunch of samples can be calculated at once. If the amount of time to wait is known, then a bunch of blocks can be processed in one shot while waiting for the next piece of code to run. |
Yes, that is correct. The exception is in the case of feedback where doing it this way will lead to errors due to there being a effective delay the length of the block-size in the feedback path. What we'll have is block processing for the general case and no block processing in the case of feedback loops in the UGen graph.
_________________
Kassen |
|
|
Back to top
|
|
|
radarsat1
Joined: Mar 14, 2008
Posts: 85
Location: Montreal
|
| Posted: Mon Jan 12, 2009 10:03 am Post subject:
|
|
|
| Quote: |
I mean that you can reason about moments between samples. This is important for execution order and also means rounding errors in when events actually take effect (so affect the sound) won't carry. or, to put it bluntly;
.5::samp => dur short_time; //this is valid |
crazy, i never thought of even trying this.. ;-) |
|
|
Back to top
|
|
|
Kassen
Janitor
Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3
|
| Posted: Mon Jan 12, 2009 9:35 pm Post subject:
|
|
|
You think that's crazy? According to my (rather casual) math our double-floats used for variables of type time and dur mean we can reason about moments in-between CPU cycles. Now *that* is what I call "strongly timed", I also feel that might be "strongly related" to ChucKists tending towards the slightly crazy.
On some level this is mind-bogglingly insane, on a practical one this means that (if you really wanted to) you can write in-line DSP that actually oversamples compared to the sample-rate, performs some operation (maybe a EQ) and downsample again, sending the result to a Step or Impulse.
It's one of those things that makes you sleep better; you wouldn't ever actually do it but it's comforting to know you *could* if you really wanted to, it's comforting to know that something that insane would be quite small, code-wise (not CPU-wise!).
Practical implementations are left as a exercise to the reader, no costs for psychological damage that may occur will be refunded, no warranties, no refunds, please mind your speakers and neighbours ;¬).
_________________
Kassen |
|
|
Back to top
|
|
|
Inventor
Stream Operator
Joined: Oct 13, 2007
Posts: 6221
Location: near Austin, Tx, USA
Audio files: 270
|
| Posted: Tue Jan 13, 2009 6:20 pm Post subject:
|
|
|
| Kassen wrote: | | You think that's crazy? According to my (rather casual) math our double-floats used for variables of type time and dur mean we can reason about moments in-between CPU cycles. Now *that* is what I call "strongly timed", I also feel that might be "strongly related" to ChucKists tending towards the slightly crazy. ;¬). |
Um, guys, I'm a ChucKist and I'm crazy. Certifiably crazy, just ask my psychiatrist. In fact, the United States government agrees that I'm crazy. So there, proof! haha!
_________________
"Let's make noise for peace." - Kijjaz |
|
|
Back to top
|
|
|
Kassen
Janitor
Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3
|
| Posted: Tue Jan 13, 2009 8:14 pm Post subject:
|
|
|
Indeed! And when the US government say anything it must be true.
;¬)
_________________
Kassen |
|
|
Back to top
|
|
|
|
Forum index » DIY Hardware and Software » ChucK programming language
FAQ
Calendar
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Chat Room
