You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've been looking into how to speed up build times. I found that asm-processor adds non negligible overhead (due to python startup and imports, the asm-processor code itself runs in negligible time)
replace floats by the IEEE-754 binary representation ("in hex") in CutsceneData
convert encoding from utf-8 to euc-jp
run ido on the processed source
Note: oot is not using GLOBAL_ASM, the main feature of asm-processor, since gc-eu-mq-dbg was matched
it saves ~25% of time for building src/
(from built, rm -rf build/gc-eu-mq-dbg/src && time make)
in details, on my machine: make -j1: 71s -> 54s (-24%) make -j4: 27s -> 20s (-26%) make -j8: 22s -> 17s (-23%)
This shows we have a lot of time to gain from not using asm-processor in the build process
An option "option-crwasmp" is to introduce above program "crwasmp" into the repo, replacing $(PYTHON) tools/asm_processor/build.py in the Makefile with it.
Another option "option-justusehex" would be to have ZAPD write CutsceneData floats directly as IEEE-754 (possibly with the float value as a comment like 0x42142142 /* 421.0f */).
Then all that's left to do before calling ido is the utf-8 to euc-jp encoding conversion, which is easily done with the iconv program. As a bonus this allows removing #pragma asmproc recurse.
Either way we would still keep asm-processor in the repo, which could selectively be used on specific files (cherry-pick in the makefile), if we do end up reintroducing GLOBAL_ASMs in the repo.
The two options are outlined in more details below
option-crwasmp has been tested, it's what I have right now.
There's no reason to believe option-justusehex would be slower (should be (marginally) faster, even)
Modify the makefile to use crwasmp in place of asm-processor: Dragorn421@6b31542
option-justusehex
modify ZAPD to write hex IEEE-754 instead of floats in CutsceneData (e.g. 0x42142142 or 0x42142142 /* 421.0f */ instead of 421.0f), toggled by a config option
patch ZAPD upstream
pull ZAPD into zeldaret/oot
change config to write IEEE-754
remove asm-processor usage, instead use the iconv program (pseudo-command: preproc=`mktemp`; iconv -f utf-8 -t euc-jp -o input $preproc; ido FLAGS -o output $preproc; rm -f $preproc)
remove no-longer-needed #pragma asmproc recurse
option-donothing
it is an option but please not this one
The text was updated successfully, but these errors were encountered:
I've been looking into how to speed up build times. I found that asm-processor adds non negligible overhead (due to python startup and imports, the asm-processor code itself runs in negligible time)
I wrote a C program "crwasmp" https://github.com/Dragorn421/DragoStuff/tree/crwasmp that performs what we currently use asm-processor for, that is
Note: oot is not using
GLOBAL_ASM
, the main feature of asm-processor, since gc-eu-mq-dbg was matchedit saves ~25% of time for building src/
(from built,
rm -rf build/gc-eu-mq-dbg/src && time make
)in details, on my machine:
make -j1
: 71s -> 54s (-24%)make -j4
: 27s -> 20s (-26%)make -j8
: 22s -> 17s (-23%)This shows we have a lot of time to gain from not using asm-processor in the build process
An option "option-crwasmp" is to introduce above program "crwasmp" into the repo, replacing
$(PYTHON) tools/asm_processor/build.py
in the Makefile with it.Another option "option-justusehex" would be to have ZAPD write CutsceneData floats directly as IEEE-754 (possibly with the float value as a comment like
0x42142142 /* 421.0f */
).Then all that's left to do before calling ido is the utf-8 to euc-jp encoding conversion, which is easily done with the
iconv
program. As a bonus this allows removing#pragma asmproc recurse
.Either way we would still keep asm-processor in the repo, which could selectively be used on specific files (cherry-pick in the makefile), if we do end up reintroducing
GLOBAL_ASM
s in the repo.The two options are outlined in more details below
option-crwasmp has been tested, it's what I have right now.
There's no reason to believe option-justusehex would be slower (should be (marginally) faster, even)
option-crwasmp
option-justusehex
0x42142142
or0x42142142 /* 421.0f */
instead of421.0f
), toggled by a config optioniconv
program (pseudo-command:preproc=`mktemp`; iconv -f utf-8 -t euc-jp -o input $preproc; ido FLAGS -o output $preproc; rm -f $preproc
)#pragma asmproc recurse
option-donothing
it is an option but please not this one
The text was updated successfully, but these errors were encountered: