I have a question on acmod_flag2list function of Pocketsphinx (My question is
in
reference to FSG implementation).
In this function, active senones are checked by looking into
"senone_active_vec" bitvector.
A "delta" process is then done where an 8 bit array "senone_active" is created
from the
"senone_active_vec" bitvector. This array (senone_active) has the active
senone values in delta
form.
The way this array is produced, it creates many more senones that are actually
active as it tries to
bridge the differential by adding extra senones to bridge the gap.
When senone scoring is done, all the senones in senone_active list are scored
(this includes those
extra senones too).
Looks like scores of these "extra" senones don't get used annywhere
downstream. My question is
why are these extra senones created and why are their scores calculated?
Large differentials result into too many of these extra senones. If this delta
step is removed, an
FSG based application can benifit by only keeping mixture weights (from
sendump file) for only
the total number of unique senones present in the lexical tree.
Is this hypothesis correct ?
Regards,
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Large differentials result into too many of these extra senones. If this
delta step is removed, an FSG based application can benifit by only keeping
mixture weights (from sendump file) for only the total number of unique
senones present in the lexical tree. Is this hypothesis correct ?
Yes, use 8 bits to encode active senone list. Seems to have a
negligible effect on the number of senones evaluated and is definitely
faster (we have reduced the senone_active array from 20k to
5k... which should be pretty nice on machines with 16k of cache)
Hi Nickolay,
I have a question on acmod_flag2list function of Pocketsphinx (My question is
in
reference to FSG implementation).
In this function, active senones are checked by looking into
"senone_active_vec" bitvector.
A "delta" process is then done where an 8 bit array "senone_active" is created
from the
"senone_active_vec" bitvector. This array (senone_active) has the active
senone values in delta
form.
The way this array is produced, it creates many more senones that are actually
active as it tries to
bridge the differential by adding extra senones to bridge the gap.
When senone scoring is done, all the senones in senone_active list are scored
(this includes those
extra senones too).
Looks like scores of these "extra" senones don't get used annywhere
downstream. My question is
why are these extra senones created and why are their scores calculated?
Large differentials result into too many of these extra senones. If this delta
step is removed, an
FSG based application can benifit by only keeping mixture weights (from
sendump file) for only
the total number of unique senones present in the lexical tree.
Is this hypothesis correct ?
Regards,
Yes, seems so. From the changlog
r8745 | dhdfu | 2008-09-02 17:19:23 -0400 (Tue, 02 Sep 2008) | 5 lines
Yes, use 8 bits to encode active senone list. Seems to have a
negligible effect on the number of senones evaluated and is definitely
faster (we have reduced the senone_active array from 20k to
5k... which should be pretty nice on machines with 16k of cache)
r8744 | dhdfu | 2008-09-02 16:54:59 -0400 (Tue, 02 Sep 2008) | 3 lines
Encode senone_active as deltas and use fewer bits (in fact we can use
8 bits and just eat the occasional extra senone...)
I also dont quite get this optimization.