Свежие комментарии

Эттта. DDK - это driver developers kit? Откудова там msvcrt.dll -то? Тамж тока мессия ntoskrnl.exe и пророк его hal.dll )))

Про SQLite не все знают.

Кэшироваться должно хорошо, я ж в одно место пишу :)
С конфликтами в случае безусловной записи должно быть ещё хуже, все треды пишут одновременно, а с условием только очень некоторые. А получается всё равно сильно медленнее.

Именно так.

Чтоб было понятнее, о чем речь, вот тестовый пример: http://dil.pp.ru/xfer-test.zip

Если вообще ничего никуда не писать (возможно при этом проверяющая функция вообще не вызывается, потому что результаты её работы не используются и побочных эффектов нет): 1644 миллиона проверок в секунду.

Если у функции включить побочный эффект в виде инкрементирования элемента глобальной структуры (инкрементирование работает, его видно потом в хосте): 1497 миллионов проверок.

Добавляем безусловное инкрементирование другого элемента глобальной структуры после вызова функции: 1320 миллионов.

Переносим это инкрементирование внутрь if(1): ничего не меняется.

Меняем условие на if(result): скорость уменьшается в три раза, 467 миллионов/c.

Не так заметно, как на живой программе, но всё же.
Пока все треды писали, они писали быстро. Потом большинство писать перестало, а оставшееся меньшинство стало писать втрое медленнее. Фигня какая-то..

Нет, указатель был на локальную переменную вызывающей функции. По значению этой переменной после вызова и определяется, подходящий был аргумент, или нет.
А в глобальной памяти только выходной массив matchingArgs.

Да не, современный мыскуль уже почти хорош в плане транзакционности. Другое дело, что нормальные запросы там бывает сложно написать, но последователям .DBF не привыкать. Собственно, фиг с ним, с мыскулем, раз уж пЕсатели его выбрали, но можно же иногда без автокоммита работать?

А любов хостеров к мыскулю ты чем объяснишь? "Берём..." -- что?

Функция имеет тип void, а результат возвращает в переменную через переданный ей указатель. Если компилятор решил такое заоптимизировать в ноль, то его аффторов надо гнать погаными тряпками вон из профессии.
Надо будет проверить, правда ли это..

вот насчет предикатов непонятно. в мануале написано, что так могут оптимизироваться операции из 4-7 команд, а сколько занимает копирование 8 байт, я не знаю.
В любом случае, это быстрая опреация, пусть бы остальные треды в это время постояли, это на общем фоне сущая мелочь, а оно почему-то страшно тормозит.

Профайлер еще не пробовал, за идею спасибо, она мне почему-то в голову не пришла :)

Даже не atomic. Простая условная запись даже в одну и ту же ячейку тормозит процесс на порядки.
if(match) {
matchingArgs[0] = arg;
}

arg представляет собой unsigned char[8].
matchingArgs - глобальный массив, объявленный с атрибутом __device__. (Если быть совсем точным, это часть структуры, состоящей из счетчика, семафора, флага переполнения и собственно массива, но не думаю, что это принципиально).

А если написать if(1), что вероятно оптимизируется компилятором в отсутствие if вообще, то торможения практически нет. То есть, проблема не в самой по себе записи, а именно в её условности.

Так существуют какие-то идеологически более правильные способы возвращать такие наборы результатов?

Объясним, это DBF 21-го века!

Это, я так понимаю, в шестерке? Надо будет посмотреть, сохранился ли этот баг в семерке, там работа с БД существенно переделана, в том числе и в части поддержки транзакций.

примерно один-два на миллион

собственно результат, выданный функцией, не нужен. нужно записать только вход, на котором функция выдала ненулевое значение