Skip to content
This repository has been archived by the owner on Feb 27, 2024. It is now read-only.

increased search threshold for large database #30

Merged
merged 1 commit into from
Apr 2, 2018
Merged

Conversation

zjing14
Copy link
Contributor

@zjing14 zjing14 commented Mar 28, 2018

I got the following Jenkins failure for large search time with a large database. Thus, I increased the allotted time threshold.

test 10/32
tC0_tA0_tB0_colMaj1_m81_n91_k67_lda90_ldb77_ldc93_ws1000000_f32
Found device gfx900 @{[64 CUs] [1500 MHz]}. Use/modify a CLHint to change.

Entering new descent.
{0.05 <<< @t=3.009e-06[s] <<< 0.1} {0 <<< @i=0 <<< 100000}
geometry : tC0_tA0_tB0_colMaj1_m81_n91_k67_lda90_ldb77_ldc93_ws1000000_f32
allotted time : 0.100000
Warmstart requested [@ rank 0] Nearest match in kernel cache:
device : gfx803' constraints : '
geometry : `tC0_tA0_tB0_colMaj1_m77_n77_k77_lda77_ldb77_ldc77_ws0_f32'
Time in get_default : 0.099062 [s]
stopping the search because allotted time has been surpassed
terminate called after throwing an instance of 'MIOpenGEMM::miog_error'
what():

@zjing14 zjing14 requested a review from dagamayank March 28, 2018 17:02
Copy link
Contributor

@newling newling left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like a safe change. I don't understand the details (0.1 should be enough time to find nearest match in a huge db if there is no compiling / benchmarking ... ) but I approve (0.1 was probably chosen randomly anyway).

@zjing14 zjing14 merged commit 231de70 into master Apr 2, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants