- Status Closed
- Percent Complete
- Task Type Patches
- Category Codecs
- Assigned To No-one
- Operating System PortalPlayer-based
- Severity Low
- Priority Very Low
- Reported Version Daily build (which?)
- Due in Version Undecided
-
Due Date
Undecided
- Votes
- Private
FS#8179 - MPC: small speed up
Small speed up for mpc decoding (+2.7%).
Changes:
- reduced ldmia-calls through reading 8 instead of 4 register in one single ldmia
mpc_opt_v1.patch
(7.9 KiB)
Loading...
Available keyboard shortcuts
- Alt + ⇧ Shift + l Login Dialog / Logout
- Alt + ⇧ Shift + a Add new task
- Alt + ⇧ Shift + m My searches
- Alt + ⇧ Shift + t focus taskid search
Tasklist
- o open selected task
- j move cursor down
- k move cursor up
Task Details
- n Next task
- p Previous task
- Alt + ⇧ Shift + e ↵ Enter Edit this task
- Alt + ⇧ Shift + w watch task
- Alt + ⇧ Shift + y Close Task
Task Editing
- Alt + ⇧ Shift + s save task
Are you absolutely sure this patch is any faster? Theoretically, you're saving four cycles per loop here, and in the process using so many registers that even common variables like the loop counter 'k' is evicted from the registers and needs to be reloaded on each loop end, something which takes 3 cycles, and a further 3 cycles to store back.
Had similar thoughts about this. Nevertheless the measurement from svn against this change clearly shows the small speed up (at least on 5G).
For the speed optimized case, there is _just_ enough regs left for the counter, but not in the unoptimized case. Have you checked if that is any faster too?
Now you've got me :/ I'll retest and post results as well as (maybe) a corrected patch.
Ok, tested in non-optimized case. It's 279.99% (new) against 279.93% (svn) – so still a bit faster :o)
Nevertheless I will undo the changes for non-optimized case as it's better to leave code as is, if there is no significant result.