[Cs-dev] differences between parsers

[Cs-dev] differences between parsers

Date	2011-12-05 13:00
From	John Lato
Subject	[Cs-dev] differences between parsers
	Hello, I've been looking at the opcode list produced by the old and new parsers to see how they differ, with a goal of getting the new parser to match the performance of the old. I'm printing the following after the orc. is parsed: for (instrnum = 0; instrnummaxinsno; instrnum++) { instrtxt = csound->instrtxtp[instrnum]; if (!instrtxt) { break; } csound->Message(csound, "Instrument %s\n", instrtxt->insname); for (otxt = instrtxt->nxtop; otxt; otxt = otxt->nxtop) { TEXT t = otxt->t; csound->Message(csound, " %s\n",t.opcod); } } One big difference is that, when the new parser is used, there is an extra assignment for global variable writes. The final statement in instr. 2 of trapped.csd is garvb = garvb + (asig * p7) With the old parser, this results in mul.ak add.aa endin whereas with the new parser I get mul.ak add.aa =.a endin I can't find any corresponding '=.a' in the output from the old parser. Is there possibly an accumulating variant of add.aa, or some other means of assignment that is unaccounted-for by my method? I don't see how the signal gets included in the global send (but it does, the audio output is identical). Thanks, John L. ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net

Date	2011-12-05 14:32
From	Tito Latini
Subject	Re: [Cs-dev] differences between parsers
Attachments	None

Date	2011-12-05 14:34
From	Tito Latini
Subject	Re: [Cs-dev] differences between parsers
Attachments	None

Date	2011-12-05 14:37
From	Steven Yi
Subject	Re: [Cs-dev] differences between parsers
	Also one difference to note, with the new parser, if I remember correctly, expressions are getting rewritten with temp variables holding the result. So you'd get something like: _atemp1 mul.ak asig, p7 _atemp2 add.aa garvb, _atemp1 garvb =.a _atemp2 This to me is fine as it's closer to SSA to use for optimizations. >From Tito's other email showing the line in rdorch.c, it seems that kind of thing should be done with the new parser in the optimization pass in Engine/csound_orc_optimize.c. steven On Mon, Dec 5, 2011 at 2:32 PM, Tito Latini wrote: > See csound5/ChangeLog:3516 > > tito > > On Mon, Dec 05, 2011 at 01:00:27PM +0000, John Lato wrote: >> Hello, >> >> I've been looking at the opcode list produced by the old and new >> parsers to see how they differ, with a goal of getting the new parser >> to match the performance of the old. I'm printing the following after >> the orc. is parsed: >> >> for (instrnum = 0; instrnummaxinsno; instrnum++) { >> instrtxt = csound->instrtxtp[instrnum]; >> if (!instrtxt) { >> break; >> } >> csound->Message(csound, "Instrument %s\n", instrtxt->insname); >> for (otxt = instrtxt->nxtop; otxt; otxt = otxt->nxtop) { >> TEXT t = otxt->t; >> csound->Message(csound, " %s\n",t.opcod); >> } >> } >> >> One big difference is that, when the new parser is used, there is an >> extra assignment for global variable writes. The final statement in >> instr. 2 of trapped.csd is >> garvb = garvb + (asig * p7) >> >> With the old parser, this results in >> mul.ak >> add.aa >> endin >> >> whereas with the new parser I get >> mul.ak >> add.aa >> =.a >> endin >> >> I can't find any corresponding '=.a' in the output from the old >> parser. Is there possibly an accumulating variant of add.aa, or some >> other means of assignment that is unaccounted-for by my method? I >> don't see how the signal gets included in the global send (but it >> does, the audio output is identical). >> >> Thanks, >> John L. >> >> ------------------------------------------------------------------------------ >> All the data continuously generated in your IT infrastructure >> contains a definitive record of customers, application performance, >> security threats, fraudulent activity, and more. Splunk takes this >> data and makes sense of it. IT sense. And common sense. >> http://p.sf.net/sfu/splunk-novd2d >> _______________________________________________ >> Csound-devel mailing list >> Csound-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/csound-devel > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure > contains a definitive record of customers, application performance, > security threats, fraudulent activity, and more. Splunk takes this > data and makes sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-novd2d > _______________________________________________ > Csound-devel mailing list > Csound-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/csound-devel ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net

Date	2011-12-05 15:01
From	John Lato
Subject	Re: [Cs-dev] differences between parsers
	Thanks for the pointers; I'll look into it. Steven, you're correct about this as well. It has to do with how T_ASSIGN expressions are expanded. I'm not sure if it's smarter to clean this up after the fact, or keep it from being expanded in the first place. John L. On Mon, Dec 5, 2011 at 2:37 PM, Steven Yi wrote: > Also one difference to note, with the new parser, if I remember > correctly, expressions are getting rewritten with temp variables > holding the result. So you'd get something like: > > _atemp1 mul.ak asig, p7 > _atemp2 add.aa garvb, _atemp1 > garvb =.a _atemp2 > > This to me is fine as it's closer to SSA to use for optimizations. > >From Tito's other email showing the line in rdorch.c, it seems that > kind of thing should be done with the new parser in the optimization > pass in Engine/csound_orc_optimize.c. > > steven > > On Mon, Dec 5, 2011 at 2:32 PM, Tito Latini wrote: >> See csound5/ChangeLog:3516 >> >> tito >> >> On Mon, Dec 05, 2011 at 01:00:27PM +0000, John Lato wrote: >>> Hello, >>> >>> I've been looking at the opcode list produced by the old and new >>> parsers to see how they differ, with a goal of getting the new parser >>> to match the performance of the old. I'm printing the following after >>> the orc. is parsed: >>> >>> for (instrnum = 0; instrnummaxinsno; instrnum++) { >>> instrtxt = csound->instrtxtp[instrnum]; >>> if (!instrtxt) { >>> break; >>> } >>> csound->Message(csound, "Instrument %s\n", instrtxt->insname); >>> for (otxt = instrtxt->nxtop; otxt; otxt = otxt->nxtop) { >>> TEXT t = otxt->t; >>> csound->Message(csound, " %s\n",t.opcod); >>> } >>> } >>> >>> One big difference is that, when the new parser is used, there is an >>> extra assignment for global variable writes. The final statement in >>> instr. 2 of trapped.csd is >>> garvb = garvb + (asig * p7) >>> >>> With the old parser, this results in >>> mul.ak >>> add.aa >>> endin >>> >>> whereas with the new parser I get >>> mul.ak >>> add.aa >>> =.a >>> endin >>> >>> I can't find any corresponding '=.a' in the output from the old >>> parser. Is there possibly an accumulating variant of add.aa, or some >>> other means of assignment that is unaccounted-for by my method? I >>> don't see how the signal gets included in the global send (but it >>> does, the audio output is identical). >>> >>> Thanks, >>> John L. >>> >>> ------------------------------------------------------------------------------ >>> All the data continuously generated in your IT infrastructure >>> contains a definitive record of customers, application performance, >>> security threats, fraudulent activity, and more. Splunk takes this >>> data and makes sense of it. IT sense. And common sense. >>> http://p.sf.net/sfu/splunk-novd2d >>> _______________________________________________ >>> Csound-devel mailing list >>> Csound-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/csound-devel >> >> ------------------------------------------------------------------------------ >> All the data continuously generated in your IT infrastructure >> contains a definitive record of customers, application performance, >> security threats, fraudulent activity, and more. Splunk takes this >> data and makes sense of it. IT sense. And common sense. >> http://p.sf.net/sfu/splunk-novd2d >> _______________________________________________ >> Csound-devel mailing list >> Csound-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/csound-devel > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure > contains a definitive record of customers, application performance, > security threats, fraudulent activity, and more. Splunk takes this > data and makes sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-novd2d > _______________________________________________ > Csound-devel mailing list > Csound-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/csound-devel ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net

Date	2011-12-05 20:13
From	Steven Yi
Subject	Re: [Cs-dev] differences between parsers
	Yeah, I don't know what is more proper for parsers, but I'm leaning towards a separate dedicated optimization pass. I figure it's better to have it all in one place in the code in case some complicated optimizations might depend on the more expanded out form to yield tighter code. On Mon, Dec 5, 2011 at 3:01 PM, John Lato wrote: > Thanks for the pointers; I'll look into it. > > Steven, you're correct about this as well. It has to do with how > T_ASSIGN expressions are expanded. I'm not sure if it's smarter to > clean this up after the fact, or keep it from being expanded in the > first place. > > John L. > > On Mon, Dec 5, 2011 at 2:37 PM, Steven Yi wrote: >> Also one difference to note, with the new parser, if I remember >> correctly, expressions are getting rewritten with temp variables >> holding the result. So you'd get something like: >> >> _atemp1 mul.ak asig, p7 >> _atemp2 add.aa garvb, _atemp1 >> garvb =.a _atemp2 >> >> This to me is fine as it's closer to SSA to use for optimizations. >> >From Tito's other email showing the line in rdorch.c, it seems that >> kind of thing should be done with the new parser in the optimization >> pass in Engine/csound_orc_optimize.c. >> >> steven >> >> On Mon, Dec 5, 2011 at 2:32 PM, Tito Latini wrote: >>> See csound5/ChangeLog:3516 >>> >>> tito >>> >>> On Mon, Dec 05, 2011 at 01:00:27PM +0000, John Lato wrote: >>>> Hello, >>>> >>>> I've been looking at the opcode list produced by the old and new >>>> parsers to see how they differ, with a goal of getting the new parser >>>> to match the performance of the old. I'm printing the following after >>>> the orc. is parsed: >>>> >>>> for (instrnum = 0; instrnummaxinsno; instrnum++) { >>>> instrtxt = csound->instrtxtp[instrnum]; >>>> if (!instrtxt) { >>>> break; >>>> } >>>> csound->Message(csound, "Instrument %s\n", instrtxt->insname); >>>> for (otxt = instrtxt->nxtop; otxt; otxt = otxt->nxtop) { >>>> TEXT t = otxt->t; >>>> csound->Message(csound, " %s\n",t.opcod); >>>> } >>>> } >>>> >>>> One big difference is that, when the new parser is used, there is an >>>> extra assignment for global variable writes. The final statement in >>>> instr. 2 of trapped.csd is >>>> garvb = garvb + (asig * p7) >>>> >>>> With the old parser, this results in >>>> mul.ak >>>> add.aa >>>> endin >>>> >>>> whereas with the new parser I get >>>> mul.ak >>>> add.aa >>>> =.a >>>> endin >>>> >>>> I can't find any corresponding '=.a' in the output from the old >>>> parser. Is there possibly an accumulating variant of add.aa, or some >>>> other means of assignment that is unaccounted-for by my method? I >>>> don't see how the signal gets included in the global send (but it >>>> does, the audio output is identical). >>>> >>>> Thanks, >>>> John L. >>>> >>>> ------------------------------------------------------------------------------ >>>> All the data continuously generated in your IT infrastructure >>>> contains a definitive record of customers, application performance, >>>> security threats, fraudulent activity, and more. Splunk takes this >>>> data and makes sense of it. IT sense. And common sense. >>>> http://p.sf.net/sfu/splunk-novd2d >>>> _______________________________________________ >>>> Csound-devel mailing list >>>> Csound-devel@lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/csound-devel >>> >>> ------------------------------------------------------------------------------ >>> All the data continuously generated in your IT infrastructure >>> contains a definitive record of customers, application performance, >>> security threats, fraudulent activity, and more. Splunk takes this >>> data and makes sense of it. IT sense. And common sense. >>> http://p.sf.net/sfu/splunk-novd2d >>> _______________________________________________ >>> Csound-devel mailing list >>> Csound-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/csound-devel >> >> ------------------------------------------------------------------------------ >> All the data continuously generated in your IT infrastructure >> contains a definitive record of customers, application performance, >> security threats, fraudulent activity, and more. Splunk takes this >> data and makes sense of it. IT sense. And common sense. >> http://p.sf.net/sfu/splunk-novd2d >> _______________________________________________ >> Csound-devel mailing list >> Csound-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/csound-devel > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure > contains a definitive record of customers, application performance, > security threats, fraudulent activity, and more. Splunk takes this > data and makes sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-novd2d > _______________________________________________ > Csound-devel mailing list > Csound-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/csound-devel ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net