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
This PR is a demo of shadowdash from team5. A lot of things aren't cleaned up yet, so it might be a little messy here currently. The purpose of this PR is to provide a runnable shadowdash demo for people to play around and experiment with, and perhaps fix current issues in this shadowdash demo.
How to run the demo:
First, let's create a libmanifest.so:
navigate to convertor folder: cd convertor
compile manifest: cd manifest && ./compile.sh && cd ../
convert a ninja file (e.g. zlib) to compile later:python3 convertor.py ./test_ninja_build/zlib_build.ninja
compile the manifest to libmanifest.so: cd output && ./compile.sh
Then, build shadowdash:
navigate to shadowdash root
You probably need to replace the absolute library path in CMakeLists.txt at line 220 to point to the output folder. (This should be fixed later, but for the demo, let's just do this temporarily)
run cmake -Bbuild-cmake && cmake --build build-cmake
run shadowdash:
goto the root folder of the software you want to build (e.g. zlib)
run env LD_LIBRARY_PATH="$SHADOWDASH_ROOT/convertor/output" $SHADOWDASH_ROOT/build-cmake/shadowdash all
NOTES:
default and pool syntax hasn't been added to this demo yet. We do have designed the default and pool in new language and it should be easy to add them to the demo. But again, since this is a demo and these two syntax is not very important to the building itself, so it hasn't been added yet. One consequence is that the build target must be manually specified when run the shadowdash (e.g. shadowdash all instead of just shadowdash).
This version of demo just experimented with pre-defining string variables, which significantly reduced the compilation time from ~3min to 40 seconds for LLVM.
The rule object is currently still defined within a single file, which causing it taking ~15 seconds to compile. This can be refactored and split the rule objects into multiple files just like build objects. But since 15 seconds is still not the biggest overhead of current manifest compilation, so this could be implemented later once the biggest overhead (sub-manifest compilation) is addressed.
metric endpoint is already added for shadowdash for benchmark purpose. by running ./shadowdash all -d stats -n (-n is optional but recommended), the time spent on running manifest can be shown. If you want to measure the time multiple times, a python script (bench.py under convertor folder) is already provided to do this. The script currently does not take any argument, so you probably need to adjust the parameter at the beginning of the script to make it run sccessfully.
Under convertor/convertors folder, you may see there are a lot of different versions of convertors. The most up to date version is convertor_split_func_new.py, which is already soft-linked by convertor/convertor.py.
There are also 3 optional parameters that can be adjust at the beginning of the convertor script.
blocks means splitting the manifest into how many blocks
optimizer specifies the c++ optimizer (O0, O1, O2, etc)
job_threads specifies using how many threads to build sub-manifests.
@kyotov Hey, professor, here is an shadowdash demo that you can play around. Currently I have already implemented part of the suggestions you gave last time: 1. concatenating literal strings 2. pre-define all the strings 3. refactor manifest.h and put the function definition into another file
The compilation speed does improve a lot by these suggestions (primarily from 2nd suggestion), and the manifest of LLVM can be compiled within 40 seconds with O0. (or 2 min with O1, 5min with O3). However, the runtime speed does not improve a lot.
I am currently thinking about using just references for all the strings and potentially other objects, which should reduce a lot of object copying overhead. Since now all the strings are pre-defined and live in the global scope, so they should not be destructed anymore and we can just reference them. I havn't implemented this yet, so this might be my next goal.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR is a demo of shadowdash from team5. A lot of things aren't cleaned up yet, so it might be a little messy here currently. The purpose of this PR is to provide a runnable shadowdash demo for people to play around and experiment with, and perhaps fix current issues in this shadowdash demo.
How to run the demo:
cd convertorcd manifest && ./compile.sh && cd ../python3 convertor.py ./test_ninja_build/zlib_build.ninjacd output && ./compile.shcmake -Bbuild-cmake && cmake --build build-cmakeenv LD_LIBRARY_PATH="$SHADOWDASH_ROOT/convertor/output" $SHADOWDASH_ROOT/build-cmake/shadowdash allNOTES:
defaultandpoolsyntax hasn't been added to this demo yet. We do have designed thedefaultandpoolin new language and it should be easy to add them to the demo. But again, since this is a demo and these two syntax is not very important to the building itself, so it hasn't been added yet. One consequence is that the build target must be manually specified when run the shadowdash (e.g.shadowdash allinstead of justshadowdash).ruleobjects into multiple files just likebuildobjects. But since 15 seconds is still not the biggest overhead of current manifest compilation, so this could be implemented later once the biggest overhead (sub-manifest compilation) is addressed../shadowdash all -d stats -n(-n is optional but recommended), the time spent on running manifest can be shown. If you want to measure the time multiple times, a python script (bench.pyunderconvertorfolder) is already provided to do this. The script currently does not take any argument, so you probably need to adjust the parameter at the beginning of the script to make it run sccessfully.convertor/convertorsfolder, you may see there are a lot of different versions of convertors. The most up to date version isconvertor_split_func_new.py, which is already soft-linked byconvertor/convertor.py.blocksmeans splitting the manifest into how many blocksoptimizerspecifies the c++ optimizer (O0, O1, O2, etc)job_threadsspecifies using how many threads to build sub-manifests.