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

Ну уж если разрешать restrict в C++, то, думается мне, разрешить его только для указателей или впихнуть ещё и к референсам -- вопрос, опять же, чисто политический, а технически решается одной локальной правкой грамматики или ручного парсера.

По-моему, вы разговариваете с голосами в своей голове. Откуда-то взяли deduplication и "нагрузку на процессор" (это было 22 сентября, несколько сообщений вверх).
Теперь "хостинг" и "банк". Нет, я не работаю в банке. Нет, я не работаю в хостинговой компании.
Да, в FreeBSD ZIL по-умолчанию включен только на синхронных операциях. То есть в данной ситуации нерелевантен.

Флаги создания FS, сюрприз, тоже нерелевантны. И NTFS и ext4 дали скорость практически равную голому диску, вообще без fs, то есть оверхед - копеечный. А ZFS - нет, не дала. С учетом наличия SRP target только под Linux - дальше тестировать смысла не было.

(пожимает плечам) добавить. const же те может быть. Опять же, с точки зрения оптимизатора нет никакой разницы (я очень удивлюсь, если на том уровне есть разница). Она же вся съедается на этапе синтаксического анализа. Референсы -- это же чистый syntatic shugar, нет? Ну, ещё NULL не могут быть и должны быть инициализированы.

Ну тогда настаивать на restricted, благо чистых C++ компиляторов не бывает (или бывают?) и, по идее, поддержка restricted в C++ -- вопрос упёртости авторов компилятора в стандарт, т.е. политический, а не технический.

1) Не должны, если не указано явно. Но вообще, надо не забывать, что мы тут о макроассемблере рассуждаем. Везде пишут -- боитесь переноса в регистр/овероптимизации -- пишите волатайл. Это правильно. А тут вдруг компилятор умничает без волатайла. Это неправильно.

2) Ну а нет переносимого способа в рамках языка. И командная строка мне нравится как непереносимый способ куда больше, чем __attribute__(()). Нету ключика -- код будет корректный, но тормозной. Никакой опасности. То, что уровень оптимизации через командную строку задаётся, тебя же не смущает, правда? А это вот такая _опасная_ оптимизация, которую надо включать отдельно. Нормальный подход, нет? Кстати, не про это ли -fno-strict-aliasing в gcc? ;-)

3) Я не читал стандарта C99 (где бы его взять бесплатно), но в мурзилках сказано про pointer declaration, без уточнения в аргументности. Я там не помню, кому всё это прописали. И, да, опять же, расширение, которое пришло из C99, мне кажется меньшим злом, чем любые кастомные расширения.

1) В случае инкремента счетчика вообще должны быть атомики.
Но это - другая история, мы же о векторизующих компиляторах, а не о многопоточности.

2) "Опции командной строки" - отказать. Это управление а) на уровне файла с исходниками б) не средствами языка. в) несовместимое

3) stdlib весь объявлен как extern "C" - и это аргументы функций. Только вот memmove - уж точно не restrict, хотя вот в некоторых реализациях вроде memcpy бывает c restrict.
Впрочем, объявление __restrict для члена класса - 2012-я студия съела. Надо исследовать, что оно там наслесарит.

Это не многопоточность, это векторность.

В случае инкремента счётчика нет там никакой векторности.

Но никто же не может ему обещать

Может. Программист. Опцией командной строки.

стандартного способа описать ptr как restrict - в C++ нету.

А ключевое слово restrict -- оно только к аргументам функции применимо? Вообще пришут про просто pointer declaration.
Ну да, оно C99, но оно вовсю используется, например, в stdlib (во всяких memmove и прочих) уже, а stdlib и в С++ должен же работать.

(ссылка побилась)
Писать ядра на plain C, делов-то ;-)

Это же даже не альясинг, это что-то другое. Это какой-то неявный волатайл. Я не уверен, что стандарт обязывает тут вставлять волатайл компилятором. С глобальными-то переменными такой проблемы не было (точнее -- типична обратная проблема, по крайней мере у микроконтроллерщиков, которые электронщики, а не программисты -- не написали волатайл и удивляются, что цикл ожидания события стал мёртвым. 100500 раз видел такие посты).

Т.е. я плохо понимаю, зачем компиляторы так себя ведут -- если раньше долгие годы с глобалами они поступали прямо противоположным способом, а именно не учитывали многопоточность.

Ну почему же 300, всего 168.

И если качать самому, а не виндой - то можно лишнее оторвать.

Дык у меня они же даже не отдельно стоят, у меня их винда ставит, я эти безумные 300 мегабайт с сайта никогда и не качал! И всё равно впихивают 100500 контрольных панель, пунктов контекстного меню и прочего мусора! А у меня и ни одной 3D-программы то на компьютере нет. Ну, кроме фотошопа :)

Я ничего не знаю о креевских компиляторах и векторных процессорах. Но подозреваю что
а) там именно "векторные типы", может быть переменной длины, но исходно векторные т.е. можно написать A=B+C и это развернется в цикл внутри
б) и это фортран, где нет указателей, а значит нет и алиасинга т.е. компилятор не должен предполагать что в A=B+C на самом деле попытаются запихать A=&(A[1])+&[A[2]) (смысл понятен, я надеюсь).

И с векторными типами, пусть фиксированной длины, особых проблем то нет, они даже векторизуются неплохо. Ну, в моих прошлогодних экспериментах GCC с этим плохо справился, а clang - вполне ничего.

Проблема с векторизацией - она в тех местах, где есть зависимости между итерациями цикла (которые могут быть и ложными, но компилятору мозгов не хватает это распознать).

А про gather там у меня - это важное уточнение. Отсутствие чтения "по индексу" заставляет городить всякие ужасы, без которых можно было бы обойтись.

При этом перенос впрямую (перекомпиляцией) векторизуемого кода с SSE/AVX - возможен, но не всегда будет оптиммальным т.к. инструкции могут больше (gather, как минимум).
Ну а так компилятор не справится понять, что можно векторизовать больше?

Вообще, я тут слушаю курсеровскую Comuer Arhitecture, довольно бестолковый курс, но вот в разделе про векторные компьютеры утверждалось, что у того же Крея компиляторы такие умные, что никаких спец-языков не надо -- всё само векторизуется если это вообще возможно. Не то что в нашем gcc. Врут? По описанию-то этот AVX уже вполне себе векторный процессор, ну длина вектора пока не супер-длинная, но уже тоже (512) ничего. Может пора достать из пыльного угла старые компиляторы наоборот? Которые, в отличие от gcc, с нуля проектировались под такие процессоры?

>Батарейки нет, впрочем это не имеет отношения к.
По ссылке в описании контроллера батарейка есть.

>Как-то нет идеи работать в таком режиме.
А ничего что в случае с ext4 и ntfs вы работаете в таком режиме ? Там нет других режимов. ZFS по умолчанию работает с банковской точностью и обязательно сохранит последнюю транзакцию. Это приводит к падению производительности, фактически колличество транзакций равно колличеству iops. Ни одна из участвующих в тестах FS не обеспечивает такую надежность. Вы сравнили скорости грузовиков со скорость банковской машины, здорово... Дла задач хостига такая надежность немного излишне ...

У NVidia это новая шиза. Раньше они все видео делали как-то сами (трансляция шла с их сайта, а не с чужого) - и выкладывали архивы, правда не сразу. А сейчас вот внезапно перешли на чужой сервис.

А глобально - мне буквально вчера объясняли, что веб убил десктопные приложения, кому дескать оно надо, если всякие google docs в вебе. На что я резонно возразил, что такое гуглозомбирование лечится получасом отсутствия интернета.