{"action":"created","issue":{"url":"https://api.github.com/repos/StrikeNP/trac_test/issues/59","repository_url":"https://api.github.com/repos/StrikeNP/trac_test","labels_url":"https://api.github.com/repos/StrikeNP/trac_test/issues/59/labels{/name}","comments_url":"https://api.github.com/repos/StrikeNP/trac_test/issues/59/comments","events_url":"https://api.github.com/repos/StrikeNP/trac_test/issues/59/events","html_url":"https://github.com/StrikeNP/trac_test/issues/59","id":330415041,"node_id":"MDU6SXNzdWUzMzA0MTUwNDE=","number":59,"title":"Improve runtime of CLUBB: Code modifications that will not change output (Trac #59)","user":{"login":"StrikeNP","id":2577059,"node_id":"MDQ6VXNlcjI1NzcwNTk=","avatar_url":"https://avatars0.githubusercontent.com/u/2577059?v=4","gravatar_id":"","url":"https://api.github.com/users/StrikeNP","html_url":"https://github.com/StrikeNP","followers_url":"https://api.github.com/users/StrikeNP/followers","following_url":"https://api.github.com/users/StrikeNP/following{/other_user}","gists_url":"https://api.github.com/users/StrikeNP/gists{/gist_id}","starred_url":"https://api.github.com/users/StrikeNP/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/StrikeNP/subscriptions","organizations_url":"https://api.github.com/users/StrikeNP/orgs","repos_url":"https://api.github.com/users/StrikeNP/repos","events_url":"https://api.github.com/users/StrikeNP/events{/privacy}","received_events_url":"https://api.github.com/users/StrikeNP/received_events","type":"User","site_admin":false},"labels":[{"id":958019852,"node_id":"MDU6TGFiZWw5NTgwMTk4NTI=","url":"https://api.github.com/repos/StrikeNP/trac_test/labels/Migrated%20from%20Trac","name":"Migrated from Trac","color":"FFFFFF","default":false},{"id":958042830,"node_id":"MDU6TGFiZWw5NTgwNDI4MzA=","url":"https://api.github.com/repos/StrikeNP/trac_test/labels/clubb_src","name":"clubb_src","color":"FFFFFF","default":false},{"id":958045675,"node_id":"MDU6TGFiZWw5NTgwNDU2NzU=","url":"https://api.github.com/repos/StrikeNP/trac_test/labels/eihoppe@uwm.edu","name":"eihoppe@uwm.edu","color":"FFFFFF","default":false},{"id":958019578,"node_id":"MDU6TGFiZWw5NTgwMTk1Nzg=","url":"https://api.github.com/repos/StrikeNP/trac_test/labels/enhancement","name":"enhancement","color":"a2eeef","default":true}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":{"url":"https://api.github.com/repos/StrikeNP/trac_test/milestones/9","html_url":"https://github.com/StrikeNP/trac_test/milestone/9","labels_url":"https://api.github.com/repos/StrikeNP/trac_test/milestones/9/labels","id":3408878,"node_id":"MDk6TWlsZXN0b25lMzQwODg3OA==","number":9,"title":"Improve runtime of CLUBB","description":null,"creator":{"login":"StrikeNP","id":2577059,"node_id":"MDQ6VXNlcjI1NzcwNTk=","avatar_url":"https://avatars0.githubusercontent.com/u/2577059?v=4","gravatar_id":"","url":"https://api.github.com/users/StrikeNP","html_url":"https://github.com/StrikeNP","followers_url":"https://api.github.com/users/StrikeNP/followers","following_url":"https://api.github.com/users/StrikeNP/following{/other_user}","gists_url":"https://api.github.com/users/StrikeNP/gists{/gist_id}","starred_url":"https://api.github.com/users/StrikeNP/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/StrikeNP/subscriptions","organizations_url":"https://api.github.com/users/StrikeNP/orgs","repos_url":"https://api.github.com/users/StrikeNP/repos","events_url":"https://api.github.com/users/StrikeNP/events{/privacy}","received_events_url":"https://api.github.com/users/StrikeNP/received_events","type":"User","site_admin":false},"open_issues":24,"closed_issues":0,"state":"open","created_at":"2018-06-07T20:00:33Z","updated_at":"2018-06-07T23:26:58Z","due_on":null,"closed_at":null},"comments":16,"created_at":"2018-06-07T20:00:36Z","updated_at":"2018-06-08T03:47:47Z","closed_at":null,"author_association":"OWNER","body":"Please start looking for ways to optimize the runtime of CLUBB. Please work with Dave on this, because he has already spent considerable time improving the runtime.  (Thanks Dave.) \n\nBoth the Sun compiler (analyzer) and the Intel compiler (VTune) have tools for assessing which parts of the code are most expensive.  Check the TWiki for information on Sun's analyzer.  We should probably add information on Intel's VTune.  Run these first to see which parts of the code are most expensive.  Concentrate on these parts of the code.  To measure runtime properly, you'll need to set debug_level = 0, turn off all output to disk, and use a computer that no one else is using (Ketley or Steele?).\n\nPlease start by looking for ways to increase the runtime that don't change the results by more than round-off.  Intel will have some optimization suggestions.  Or perhaps changing subroutines to pure or elemental will help.  You'd have to verify using VTune.\n\nLook for opportunities to compute a quantity once, store it in memory, and feed it to whatever subroutine needs it, rather than computing it twice.  (But don't do this if the quantity is updated in the meantime.)  \n\nUse BLAS to do matrix operations rather than a do loop.  \n\nCompute lhs of um/vm/edsclrm once (i.e. call windm_edsclrm_lhs once) and preserve the matrix, instead of reconstructing the matrix twice.\n\nThe SunStudio analyzer provides warning messages when it fails to optimize certain subroutines.  If we compile with -xO3 or -xO4 or higher, sometimes SunStudio can't vectorize or inline certain loops.  Also -xipo=2 tries to treat certain pure functions inline, but fails.  Perhaps we could fix these pure functions so that they can be optimized.  Intel has a free vtune package that provides similar warning messages but for the Intel compiler.\n\n\nAttachments:\n\nhttp://carson.math.uwm.edu/trac/clubb/attachment/ticket/59/TimeDiff.ods\nhttp://carson.math.uwm.edu/trac/clubb/attachment/ticket/59/TimeDiff.pdf\n\nMigrated from http://carson.math.uwm.edu/trac/clubb/ticket/59\n```json\n{\n    \"status\": \"closed\", \n    \"changetime\": \"2009-07-13T19:30:03\", \n    \"description\": \"Please start looking for ways to optimize the runtime of CLUBB. Please work with Dave on this, because he has already spent considerable time improving the runtime.  (Thanks Dave.) \\n\\nBoth the Sun compiler (analyzer) and the Intel compiler (VTune) have tools for assessing which parts of the code are most expensive.  Check the TWiki for information on Sun's analyzer.  We should probably add information on Intel's VTune.  Run these first to see which parts of the code are most expensive.  Concentrate on these parts of the code.  To measure runtime properly, you'll need to set debug_level = 0, turn off all output to disk, and use a computer that no one else is using (Ketley or Steele?).\\n\\nPlease start by looking for ways to increase the runtime that don't change the results by more than round-off.  Intel will have some optimization suggestions.  Or perhaps changing subroutines to pure or elemental will help.  You'd have to verify using VTune.\\n\\nLook for opportunities to compute a quantity once, store it in memory, and feed it to whatever subroutine needs it, rather than computing it twice.  (But don't do this if the quantity is updated in the meantime.)  \\n\\nUse BLAS to do matrix operations rather than a do loop.  \\n\\nCompute lhs of um/vm/edsclrm once (i.e. call windm_edsclrm_lhs once) and preserve the matrix, instead of reconstructing the matrix twice.\\n\\nThe SunStudio analyzer provides warning messages when it fails to optimize certain subroutines.  If we compile with -xO3 or -xO4 or higher, sometimes SunStudio can't vectorize or inline certain loops.  Also -xipo=2 tries to treat certain pure functions inline, but fails.  Perhaps we could fix these pure functions so that they can be optimized.  Intel has a free vtune package that provides similar warning messages but for the Intel compiler.\\n\", \n    \"reporter\": \"vlarson@uwm.edu\", \n    \"cc\": \"dschanen@uwm.edu\", \n    \"resolution\": \"Verified by V. Larson\", \n    \"_ts\": \"1247513403000000\", \n    \"component\": \"clubb_src\", \n    \"summary\": \"Improve runtime of CLUBB: Code modifications that will not change output\", \n    \"priority\": \"major\", \n    \"keywords\": \"\", \n    \"time\": \"2009-06-05T22:34:31\", \n    \"milestone\": \"Improve runtime of CLUBB\", \n    \"owner\": \"eihoppe@uwm.edu\", \n    \"type\": \"enhancement\"\n}\n```\n"},"comment":{"url":"https://api.github.com/repos/StrikeNP/trac_test/issues/comments/395637855","html_url":"https://github.com/StrikeNP/trac_test/issues/59#issuecomment-395637855","issue_url":"https://api.github.com/repos/StrikeNP/trac_test/issues/59","id":395637855,"node_id":"MDEyOklzc3VlQ29tbWVudDM5NTYzNzg1NQ==","user":{"login":"StrikeNP","id":2577059,"node_id":"MDQ6VXNlcjI1NzcwNTk=","avatar_url":"https://avatars0.githubusercontent.com/u/2577059?v=4","gravatar_id":"","url":"https://api.github.com/users/StrikeNP","html_url":"https://github.com/StrikeNP","followers_url":"https://api.github.com/users/StrikeNP/followers","following_url":"https://api.github.com/users/StrikeNP/following{/other_user}","gists_url":"https://api.github.com/users/StrikeNP/gists{/gist_id}","starred_url":"https://api.github.com/users/StrikeNP/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/StrikeNP/subscriptions","organizations_url":"https://api.github.com/users/StrikeNP/orgs","repos_url":"https://api.github.com/users/StrikeNP/repos","events_url":"https://api.github.com/users/StrikeNP/events{/privacy}","received_events_url":"https://api.github.com/users/StrikeNP/received_events","type":"User","site_admin":false},"created_at":"2018-06-08T03:47:47Z","updated_at":"2018-06-08T03:47:47Z","author_association":"OWNER","body":"Trac update at 2009/06/23 at 15:51\n\neihoppe@uwm.edu commented:\n\nReplying to [comment:15 vlarson@…]:\n> There are exp functions in AiryFunction.f90 at lines 922--925 and 934--936 that could be cached.  This will only affect the KK microphysics.  Therefore, in order to test the runtime improvement, use the dycoms2_rf02_ds case with khairoutdinov_kogan microphysics turned on.\n\n\nI made this change, but currently it doesn't appear to have helped the runtime--in fact, current tests are showing a little less than a .5% increase in runtime.\n\nI'm not sure what to make of this result (it seems very odd that just one case of caching would generate an average increase while the rest showed improvement), so I am recompiling and re-running the tests to see if I get any different data. Perhaps, for whatever reason, the changes didn't end up compiled or something.\n\n(as a sidenote, dycoms2_rf02_ds already uses KK microphysics by default.)\n\n~EI\n\n"}}
{"actor":{"display_login":"StrikeNP"}}