Instruction cache miss ?

Apr 3, 2010 at 4:22pm

Instruction cache miss ?

Hello maxers,

that’s a very general question about coding :

very rarely but sometimes i have an external who takes more times to execute a method first time i done it after launching max5 ; have a relationship with something like CPU instruction cache miss ?

in case of yes is there an easy way to avoid that, in case of no what it can be ?

Thanks for reply if you have few minutes, otherwise that really doesn’t matter :-)

Apr 3, 2010 at 4:53pm

if it’s not actually a cache miss, it’s going to be something conceptually similar. modern CPUs use lots of predictive techniques to trump these sorts of problems. The more costly it is to use your code, the more of an advantage you’ll likely gain from using it repeatedly.

in any case, there’s really no way to fix this without doing a warmup cycle. maybe you can use a loadbang/loadmess to get the warmup out of the way when you open the patch? or you may be able to bury a warmup in your external itself; say, if you call your function with benign arguments in the initialization code.

Apr 4, 2010 at 6:22am

Hello Brian,

Warmup cycle ; I hoped that a thing more neat was possible ; but it seems that i should have to loadbanging …

I read somewhere that limiting the size of the assembly code decrease risk to cache miss, locality principle, but I doubt that will work as GCC optimize it well, isn’t it ? ;

but perhaps i should use -fastest smallest instead of -03 fastest ? I’ll try, but as problem occurs rarely it’s hard to test, so thanks to share your experience …


Apr 4, 2010 at 7:15am

I read somewhere that limiting the size of the assembly code decrease risk to cache miss, locality principle, but I doubt that will work as GCC optimize it well, isn’t it ? ;

if it’s really an instruction cache miss, this would be the case. but you’re describing a situation where the problem just occurs the first time. this implies that your code size is not a problem.

thinking a little harder about what you’re describing, and the code from your previous posts regarding concurrency, i’m wondering if maybe the problem you’re running into is that you’re dynamically allocating memory on your external’s init but not using it until getting a message. i’m guessing that osx probably doesn’t really allocate the memory until you actually write to it (linux works this way anyhow). so the first time you write to the newly allocated memory it has to actually do the physical allocation.

btw, you have caused me to re-read man pages for sbrk and stuff that i haven’t thought about for a few years, so cheers :)

Apr 4, 2010 at 11:04am

Hello Brian,

Actually, *before*, i add few values to the data structure with a method and the memory is allocated there ; problem occurs, *later*, first time i try to read the data (with another method) … Memory allocation bug was an interesting idea, but I am afraid that it is not that.

I did what i said in previous post (even if it is useless) and wait for bug !

Thanks for your help, i’ll try to investigate a little bit more ; can be that my diagnosis misleads.

Apr 4, 2010 at 4:22pm

Hello maxers,

ok, so smaller code doesn’t work at all ;-)

a/ my asm code call and and that’s the problem ???,

b/ i look for complications (midi à quatorze heures) …

doesn’t matter ; i’ll find, argh !

Edit : can it be peridoc daily_weekly_monthly script + reset PRAM who trashes the dyld cache ???

Apr 13, 2010 at 4:25pm

Hello maxers,

so i investigate a little bit more, it turns out that I said full of stupidities … and i’ll say few others :

it seems problem is not with my external as it occurs without ;

is it possible that (in a huge abstraction patch) maxMSP loose few ms with a first time use native object ((f.e. runtime linking or paging, f.e. [jit.op] or [zl])) or is that hypothesis totaly impossible ?

I know that it is difficult to speculate so …



You must be logged in to reply to this topic.