{"action":"created","issue":{"url":"https://api.github.com/repos/dropbox/pyston/issues/433","labels_url":"https://api.github.com/repos/dropbox/pyston/issues/433/labels{/name}","comments_url":"https://api.github.com/repos/dropbox/pyston/issues/433/comments","events_url":"https://api.github.com/repos/dropbox/pyston/issues/433/events","html_url":"https://github.com/dropbox/pyston/pull/433","id":66202660,"number":433,"title":"Add a cache for JITed object code","user":{"login":"undingen","id":7397630,"avatar_url":"https://avatars.githubusercontent.com/u/7397630?v=3","gravatar_id":"","url":"https://api.github.com/users/undingen","html_url":"https://github.com/undingen","followers_url":"https://api.github.com/users/undingen/followers","following_url":"https://api.github.com/users/undingen/following{/other_user}","gists_url":"https://api.github.com/users/undingen/gists{/gist_id}","starred_url":"https://api.github.com/users/undingen/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/undingen/subscriptions","organizations_url":"https://api.github.com/users/undingen/orgs","repos_url":"https://api.github.com/users/undingen/repos","events_url":"https://api.github.com/users/undingen/events{/privacy}","received_events_url":"https://api.github.com/users/undingen/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":4,"created_at":"2015-04-03T18:23:29Z","updated_at":"2015-04-05T17:46:33Z","closed_at":null,"pull_request":{"url":"https://api.github.com/repos/dropbox/pyston/pulls/433","html_url":"https://github.com/dropbox/pyston/pull/433","diff_url":"https://github.com/dropbox/pyston/pull/433.diff","patch_url":"https://github.com/dropbox/pyston/pull/433.patch"},"body":"This is a simple cache - we still need to generate the IR but if we can find a cache file created for the exact same IR we will load it and skip instruction selection etc...\r\n\r\nOur benchmark test suite does not benefit much from this patch because the JITing time is for most tests too short.\r\n- I see a +2% slowdown on the first run against unmodified pyston (we have to do additional hashing, disk writes, pointer relocating)\r\n- on the second run it turns into a -2% speedup.\r\n- django_setup.py improves from 2.3sec to about 1.6sec.\r\n\r\nThe cache works be creating symbols for all embedded pointers which change from one pyston start to the next using the same executable (Fixed executable specific addresses will be directly emitted in order to reduce the amount of symbols which will need relocations).\r\nThe IR for the module in text representation will get crc32 hashed (I'm very open to other ideas :-)) and if we find a file with the same hash in the ```pyston_object_cache``` directory we will use it. While this approach is very safe, it fails if the IR output has not the same variable names, line numbers,... \r\nThat's why I changed the variable name assignment to us a incremental index in the name instead of the pointer value as string.\r\nEven after this patch there are still a few instances of nondeterministic IR output (but by far the most cases should get handled), I plan to improve this in a follow up patch.\r\nOn our devel machines we will generate a huge amount of cache files with this patch because the cache file only works for the exact same executable. I plan to generate a hash of the pyston executable and save the cache file in a directory with the hash name. And remove on startup all directories which do not contain this hash. Better ideas? \r\nAnother issue is that the IR is now more difficult to read because the patchpoints func destinations will all call to a dummy -1 address but there is a option to disable the cache if one has to debug something.\r\n "},"comment":{"url":"https://api.github.com/repos/dropbox/pyston/issues/comments/89818405","html_url":"https://github.com/dropbox/pyston/pull/433#issuecomment-89818405","issue_url":"https://api.github.com/repos/dropbox/pyston/issues/433","id":89818405,"user":{"login":"undingen","id":7397630,"avatar_url":"https://avatars.githubusercontent.com/u/7397630?v=3","gravatar_id":"","url":"https://api.github.com/users/undingen","html_url":"https://github.com/undingen","followers_url":"https://api.github.com/users/undingen/followers","following_url":"https://api.github.com/users/undingen/following{/other_user}","gists_url":"https://api.github.com/users/undingen/gists{/gist_id}","starred_url":"https://api.github.com/users/undingen/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/undingen/subscriptions","organizations_url":"https://api.github.com/users/undingen/orgs","repos_url":"https://api.github.com/users/undingen/repos","events_url":"https://api.github.com/users/undingen/events{/privacy}","received_events_url":"https://api.github.com/users/undingen/received_events","type":"User","site_admin":false},"created_at":"2015-04-05T17:46:33Z","updated_at":"2015-04-05T17:46:33Z","body":"Update:\r\n- @kmod I added your pull request, thanks this fixed the issue with the duplicate node names.\r\n- I changed the hash to SHA256.\r\n- I patched llvm to support const GlobalVariables as arguments to a patchpoint without having to copy the  address in a register. This fixed the \"ran out of registers during register allocation\" bug I have encountered with the object cache enabled. It works by generating symbol entries inside the stackpoint constant table. The llvm patch needs definitely a test + more comments and I'm doubtful that the patch does not introduce a problem.\r\n\r\nThe cache file corruption check is not yet implemented."}}