It's always "optimizer.exe" in the cache dir. - Alon
On Thu, Dec 18, 2014 at 6:31 PM, Chad Austin <[email protected]> wrote: > > As long as the build system can specify precisely which path the native > optimizer will live at, then it will be possible to specify the exact > dependency graph in SCons. "somewhere within the cache directory" wouldn't > be precise enough. > > > On Thu, Dec 18, 2014 at 8:16 PM, Alon Zakai <[email protected]> wrote: >> >> This is now possible with the embuilder.py tool, see earlier today on the >> mailing list. You can tell it to build the optimizer, and it gets put in >> the cache dir (which you can customize). juj is also adding an option to >> specify a location regardless of the cache dir. >> >> - Alon >> >> >> On Thu, Dec 18, 2014 at 6:03 PM, Chad Austin <[email protected]> wrote: >>> >>> On Wed, Dec 17, 2014 at 7:01 PM, Alon Zakai <[email protected]> wrote: >>> >>>> This just matters for bitcode => JS, so a parallel build of sources to >>>> bitcode would not have any issues. >>>> >>> >>> For what it's worth, I think we produce something like half a dozen >>> independent .js targets from .bc files. >>> >>> >>>> Otherwise, it would be good to add some locking mechanism for stuff >>>> like this, but as discussed in the past, it's not easy to do >>>> cross-platform. I'm open to suggestions. Also I am ok with adding an option >>>> to tell emcc to use a prebuilt copy. >>>> >>> >>> Rather than locking, my preference would be to have an option for >>> building the native optimizer to a specified location, and another option >>> to use said specified location. >>> >>> This would allow someone to express all of these dependencies directly >>> in the SCons or whatever build tool dependency graph, and thus locking >>> isn't required. >>> >>> >>>> >>>> - Alon >>>> >>>> >>>> On Wed, Dec 17, 2014 at 4:31 PM, Bruce Mitchener < >>>> [email protected]> wrote: >>>>> >>>>> Is there a way to tell emcc / whatever to pre-build this or tell it to >>>>> use a pre-built copy? >>>>> >>>>> When emcc builds things as part of a compilation run, it is tough for >>>>> a build system to handle the case where those things don't exist and we >>>>> have multiple simultaneous invocations of emcc in a parallel build ... >>>>> >>>>> - Bruce >>>>> >>>>> >>>>> On Thu, Dec 18, 2014 at 2:46 AM, Alon Zakai <[email protected]> >>>>> wrote: >>>>> >>>>>> I just merged code to enable the new native optimizer by default. >>>>>> This means that the "js opts" phase in -O2 and above will use new C++ >>>>>> code >>>>>> instead of the old JS code. This generally speeds up that phase by more >>>>>> than 3x, and since this phase is often the slowest, can have a >>>>>> significant >>>>>> positive effect on -O2 and above build times. >>>>>> >>>>>> In the big picture, this concludes the 2nd of two major code upgrades >>>>>> this year - first to replace the JS compiler with an LLVM backend in C++, >>>>>> and now to replace the JS optimizer. >>>>>> >>>>>> The native optimizer code is written in c++11, and depends on having >>>>>> a c++11 compiler and runtime library. This might not be available >>>>>> everywhere; if building it fails, emcc will automatically use the old >>>>>> optimizer. You can see messages regarding that in debug mode output >>>>>> (EMCC_DEBUG=1 in the environment). >>>>>> >>>>>> I believe we saw that the native optimizer wouldn't build on the >>>>>> windows bot, and clb disabled the test verifying build success on it >>>>>> (other.test_native_optimizer). We should probably look more into why it >>>>>> fails now. >>>>>> >>>>>> I added a new test mode, asm2nn, which runs the non-native optimizer >>>>>> (i.e. the old one), to keep test coverage of the case where the native >>>>>> optimizer can't be built. To offset the extra bot test time, I disabled >>>>>> slow2asm, which tested the old pre-fastcomp compiler in asm.js mode. I'm >>>>>> not aware of anyone using that mode - let me know if disabling those >>>>>> tests >>>>>> concerns you. Note that bot test times should improve since all the other >>>>>> optimized test modes will use the native optimizer, which is faster. >>>>>> >>>>>> Please test this on your codebases! :) All you need to do is pull >>>>>> latest incoming (on all 3 repos), which is version 1.28.2, and use that - >>>>>> the native optimizer will be utilized by default. Check in EMCC_DEBUG=1 >>>>>> output if it says, somewhere after "running js post-opts", something like >>>>>> "js optimizer using native". That implies the native optimizer is used. >>>>>> Otherwise, you might see a warning message. >>>>>> >>>>>> You can manually disable the native optimizer, if you want, with >>>>>> EMCC_NATIVE_OPTIMIZER=0 in the env. However, as mentioned before, emcc >>>>>> will >>>>>> fall back to the JS optimizer if it fails to build the native optimizer, >>>>>> so >>>>>> you shouldn't need to do so (unless perhaps you find a bug in the native >>>>>> optimizer?). >>>>>> >>>>>> - Alon >>>>>> >>>>>> P.S. The native optimizer parses asm.js code, optimizes it, and emits >>>>>> that asm.js code. To parse and unparse, I wrote a new standalone library >>>>>> for that purpose, called cashew, >>>>>> >>>>>> https://github.com/kripken/cashew >>>>>> >>>>>> It might be useful if you want a C++ library for parsing asm.js code. >>>>>> >>>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "emscripten-discuss" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to [email protected]. >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "emscripten-discuss" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "emscripten-discuss" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> >>> -- >>> Chad Austin >>> Technical Director, IMVU >>> http://engineering.imvu.com <http://www.imvu.com/members/Chad/> >>> http://chadaustin.me >>> >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "emscripten-discuss" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "emscripten-discuss" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > > > -- > Chad Austin > Technical Director, IMVU > http://engineering.imvu.com <http://www.imvu.com/members/Chad/> > http://chadaustin.me > > > -- > You received this message because you are subscribed to the Google Groups > "emscripten-discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
