MantisBT - Rosetta
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000247Rosetta[All Projects] Bad Codingpublic2013-04-09 10:312013-10-11 13:45
Reportersmlewis 
Assigned Tormoretti 
PrioritynormalSeverityminorReproducibilityalways
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version 
Fixed in Version 
Application(s) Affectedperformance benchmark (email)
Command Line UsedN/A
Developer Options
Fixed in SVN Version30259bba8f
Summary0000247: performance benchmark needs retuning
DescriptionThe performance benchmark needs retuning to have on the order of 10 seconds per test. Currently around half are under 1 second.
Steps To Reproduce
Additional InformationHere'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.

TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2013-04-09 10:31smlewisNew Issue
2013-05-19 14:40rmorettiNote Added: 0000301
2013-10-11 13:45rmorettiFixed in SVN Version => 30259bba8f
2013-10-11 13:45rmorettiStatusnew => resolved
2013-10-11 13:45rmorettiResolutionopen => fixed
2013-10-11 13:45rmorettiAssigned To => rmoretti

Notes
(0000301)
rmoretti   
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.