AZ
(и оно тут вроде было тоже, кстати)
Size: a a a
2020 October 15
SP
а это уже прямая отсылка к великолепному докладу The Community с CppCon
по-моему доклад по-другому назывался
SP
(и оно тут вроде было тоже, кстати)
я проспал
AV
ошибки компилятора обычно на 200+ строк )
тут краткий пересказ. 200+ строк -- именно это и означают
AV
но, кстати, не обязательно. там может быть и буквально 5 строчек ошибка. но с этого не легче
AZ
по-моему доклад по-другому назывался
хм... никак не могу найти :(
AV
хм... никак не могу найти :(
тебе приснилось значит
*
Когда уже сделают нейронку, которая анализирует ошибки С++ компилятора и говорит, что у тебя не так?
AV
такс. лучше вот скажите, митап сейчас на ютюб транслируется куда-нибудь?
AV
Когда уже сделают нейронку, которая анализирует ошибки С++ компилятора и говорит, что у тебя не так?
дык я выше картинку постил - вот именно это и будет нейронка всегда говорить
AB
у нас начало
AB
m
У меня вопрос, ответ на который я не успею услышать: "Как часто вы проверяете поддержку simd? Вы не пробовали выносить это куда-нибудь на более высокий уровень, чтобы не проверять это в каждой функции?"
SP
У меня вопрос, ответ на который я не успею услышать: "Как часто вы проверяете поддержку simd? Вы не пробовали выносить это куда-нибудь на более высокий уровень, чтобы не проверять это в каждой функции?"
AB
у виднл задам на круглом столе
PZ
У меня вопрос, ответ на который я не успею услышать: "Как часто вы проверяете поддержку simd? Вы не пробовали выносить это куда-нибудь на более высокий уровень, чтобы не проверять это в каждой функции?"
Вот ответ как делали мы на моей прошлой работе.
1. Выделили все функции, которые могут использоваться SIMD и сделали два cpp-шника, один компилировался с SIMD, другой без.
2. Сделали header-файл с указателями на функции.
3. Если комплировался общий бинарь, то по сути на старте один раз проверялась поддержка SIMD и все указатели проставлялись на нужную версию.
4. Если компилировался бинарь под конкретную архитектуру в SIMD, тов хэдере был просто специальный ifdef, который делал typedef, чтоб компилятор мог инлайнить всякое.
Поэтому ответ на вопрос такой:
1. Если бинарь под неизвестную архитектуру - проверка была в рантайме один раз.
2. Если бинарь под известную архитектуру - это проставлялось соответствующим дефайном. Тоже один раз.
1. Выделили все функции, которые могут использоваться SIMD и сделали два cpp-шника, один компилировался с SIMD, другой без.
2. Сделали header-файл с указателями на функции.
3. Если комплировался общий бинарь, то по сути на старте один раз проверялась поддержка SIMD и все указатели проставлялись на нужную версию.
4. Если компилировался бинарь под конкретную архитектуру в SIMD, тов хэдере был просто специальный ifdef, который делал typedef, чтоб компилятор мог инлайнить всякое.
Поэтому ответ на вопрос такой:
1. Если бинарь под неизвестную архитектуру - проверка была в рантайме один раз.
2. Если бинарь под известную архитектуру - это проставлялось соответствующим дефайном. Тоже один раз.
W
У меня вопрос, ответ на который я не успею услышать: "Как часто вы проверяете поддержку simd? Вы не пробовали выносить это куда-нибудь на более высокий уровень, чтобы не проверять это в каждой функции?"
Так есть же для этих целей libcpuid. Обычно при инициализации софта проверки и осуществляю.
M
Кирилл Шабордин упоминал некое "собеседование глазами пострадавшего". В гугле чет ничего не нашел с точным совпадением.
Только заблокированный контент и форум, где ссылка на этот контент.
Может, не так ищу?
Только заблокированный контент и форум, где ссылка на этот контент.
Может, не так ищу?
AK
Кирилл Шабордин упоминал некое "собеседование глазами пострадавшего". В гугле чет ничего не нашел с точным совпадением.
Только заблокированный контент и форум, где ссылка на этот контент.
Может, не так ищу?
Только заблокированный контент и форум, где ссылка на этот контент.
Может, не так ищу?
M
Благодарю.
А вопросы там... Крайне интересные
А вопросы там... Крайне интересные