Skip to content

Commit

Permalink
Fix thread-safety in PredictSingleRow
Browse files Browse the repository at this point in the history
By using a unique lock instead of the shared lock the timings are very similar,
but predictions are correct.

Even so, by designing a small C++ benchmark with a very simple LGBM model,more threads on a simple model are slower than
the single-thread case. This is probably due to very small work units,
the lock contention overhead increases.

We should in the future benchmark with more complex models to see if supporting
threading on these calls is worth it in performance gains.

If not, then we could choose to not to provide thread-safety and remove
the locks altogether for maximal throughput.

See microsoft#3751 for timings.

See gist for benchmark code:

  https://gist.github.com/AlbertoEAF/5972db15a27c294bab65b97e1bc4c315
  • Loading branch information
AlbertoEAF committed Jan 16, 2021
1 parent f2695da commit 9f96ea0
Showing 1 changed file with 1 addition and 1 deletion.
2 changes: 1 addition & 1 deletion src/c_api.cpp
Original file line number Diff line number Diff line change
Expand Up @@ -391,7 +391,7 @@ class Booster {
Log::Fatal("The number of features in data (%d) is not the same as it was in training data (%d).\n"\
"You can set ``predict_disable_shape_check=true`` to discard this error, but please be aware what you are doing.", ncol, boosting_->MaxFeatureIdx() + 1);
}
SHARED_LOCK(mutex_)
UNIQUE_LOCK(mutex_)
const auto& single_row_predictor = single_row_predictor_[predict_type];
auto one_row = get_row_fun(0);
auto pred_wrt_ptr = out_result;
Expand Down

0 comments on commit 9f96ea0

Please sign in to comment.