| Anonymous | Login | 2024-12-04 03:24 CST |  |
| My View | View Issues |
| View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | ||||
| 0000247 | Rosetta | [All Projects] Bad Coding | public | 2013-04-09 10:31 | 2013-10-11 13:45 | ||||
| Reporter | smlewis | ||||||||
| Assigned To | rmoretti | ||||||||
| Priority | normal | Severity | minor | Reproducibility | always | ||||
| Status | resolved | Resolution | fixed | ||||||
| Platform | OS | OS Version | |||||||
| Product Version | |||||||||
| Fixed in Version | |||||||||
| Summary | 0000247: performance benchmark needs retuning | ||||||||
| Description | The performance benchmark needs retuning to have on the order of 10 seconds per test. Currently around half are under 1 second. | ||||||||
| Additional Information | Here's how to do it: It's in src/apps/benchmark/performance/ScoreEach.bench.hh. The ScoreEach instance is delcared here: ScoreEachBenchmark Score_hpatch_("core.scoring.Score_100x_hpatch",hpatch,100); The test activates the hpatch score term and then scores a fixed structure repeatedly. All that has to happen is that the number of repeats needs to be increased from its current value -- 100 -- to some larger one. | ||||||||
| Tags | No tags attached. | ||||||||
| Application(s) Affected | performance benchmark (email) | ||||||||
| Command Line Used | N/A | ||||||||
| Developer Options | |||||||||
| Fixed in SVN Version | 30259bba8f | ||||||||
| Attached Files | |||||||||
 Relationships |
|
 Relationships |
|
Notes |
|
|
(0000301) rmoretti (Attentive Developer) 2013-05-19 14:40 |
I took a look at this - there's a bunch of score terms that are running insanely fast because the test protein isn't correctly set up for the score terms to do anything useful with them. For example, there's no disulfides (so disulfide terms are very rapid), and there's no DNA/RNA, so things like dna_chi are exceedingly fast. I haven't checked all the very fast terms, but my guess is that there's some setup involved with those scoreterms which means we're not effectively profiling them, instead profiling an always-will-give-zero-energy code path. We probably will need to add some custom protein loading to some of them to get timings that are actually meaningful. |
|
Notes |
|
Issue History |
|||
| Date Modified | Username | Field | Change |
| 2013-04-09 10:31 | smlewis | New Issue | |
| 2013-05-19 14:40 | rmoretti | Note Added: 0000301 | |
| 2013-10-11 13:45 | rmoretti | Fixed in SVN Version | => 30259bba8f |
| 2013-10-11 13:45 | rmoretti | Status | new => resolved |
| 2013-10-11 13:45 | rmoretti | Resolution | open => fixed |
| 2013-10-11 13:45 | rmoretti | Assigned To | => rmoretti |
|
Issue History |
| Copyright © 2000 - 2012 MantisBT Group |
|