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

Title	Comment
Ну я тоже написал, что про конкретный случай неясно. Хотя ме	Ну я тоже написал, что про конкретный случай неясно. Хотя механизм в принципе тот же - вычисление области видимости данных и хинты к нему, но увы. Может, whole program optimization помогло бы, если вообще можно MSVC к примеру заставить это оптимизировать, что не факт. Но непереносимо конечно ни разу и вообще немного не в ту степь.
В классе объявляете? Ну еще бы не фобия, она может быть объ	В классе объявляете? Ну еще бы не фобия, она может быть объявлена, к примеру, для правильного выравнивания.
В смысле - два указателя в одном локальном куске кода.	В смысле - два указателя в одном локальном куске кода.
Алиасинг - это совсем не то, это предположение, что два разн	Алиасинг - это совсем не то, это предположение, что два разных указателя могут, на самом деле, указывать в одну и ту же memory location и, соответственно, оптимизировать надо аккуратнее. Но это может быть отрыжка от чего-то такого, да.
если интел будет продолжать "видеть всю программу", то скоре	если интел будет продолжать "видеть всю программу", то скорее всего все останется так же (с жизнью с регистром), но я попробую вечерком.
Тогда для чистоты эксперимента нужно и с локальными переменн	Тогда для чистоты эксперимента нужно и с локальными переменными тест провести. Вставить после: size_t l_iCounter = 0; что-то типа external_call(&l_iCounter); Изменится поведение у интела?
Вообще это довольно древний момент, я не уверен что применим	Вообще это довольно древний момент, я не уверен что применимо в конкретном случае, но в целом - вот: http://msdn.microsoft.com/en-us/library/aa984741(v=vs.71).aspx
Ну вот Intel C++ явно делает ЭТО как-то осмысленно.	Ну вот Intel C++ явно делает ЭТО как-то осмысленно.
Я бы согласился на "просто плохой компилятор", если бы не ув	Я бы согласился на "просто плохой компилятор", если бы не увидел у Интела в этом месте разумного поведения, зависящего от контекста.
данный пример к многопоточности отношения не имеет, это прос	данный пример к многопоточности отношения не имеет, это просто кривость или баг компилятора. компилятор по умолчанию генерирует код для однопоточного случая, применяет все известные оптимизации и не заботится об их корректности, это должен делать программист, если нужно. попробуйте переписать в виде цикла for: for(m_iCounter = 0; m_iCounter < m_iLimit && m_sBuffer[m_iCounter]; m_iCounter++) ;
я к тому, что нет ответа на ваш вопрос просто плохой компи	я к тому, что нет ответа на ваш вопрос просто плохой компилятор. Не думаю, что есть предположения про второй тред. Стандарт явно говорит про volаtile. Вряд ли в GCC решили сознательно автоматом проставить volatile (а он на самом деле не про треды:) на все переменные члены класса в угоду плохим программистам. Мне вот кажется на всяких классических RISC-ах первый вариант был бы ещё хуже чем на современных интелах. И вероятно GCC раньше так не делал.
наверное никак. Даже если я вообще переменную объявляю и не	наверное никак. Даже если я вообще переменную объявляю и не используют, её вряд ли какой-то компилятор трогать станет или удалять (у разработчиков компиляторов, какая-то фобия на эту ему)..
ну вообще-то читать тоже нужно с синхронизацией. всякие пайп	ну вообще-то читать тоже нужно с синхронизацией. всякие пайпы, очереди и т.д. это как раз про это. Если второму треду можно забить на всё, включая порядок и т.д. то и оптимизация с регистрами ничего не испортит. Но по хорошему, это конечно кривость.
А чего он такого сделает? Аксенов же померял, разница в 1.75	А чего он такого сделает? Аксенов же померял, разница в 1.75 раза, дохрена.
В-принципе, там все зависимости в .sln прописаны и работают.	В-принципе, там все зависимости в .sln прописаны и работают. Но прописаны только в .vcproj, но не в .sln (Qmake которым я все генерирую - в .sln не умеет, а при ручном создании проектов оно цепляется к моей структуре дисков и каталогов). Можно и вручную прописать в свойствах Solution. Но. На быстрых многоядерных машинах есть другая печаль (возможно, это какой-то конфликт с антивирусами или чем-то подобным): когда VisualStudio считает, что проект libraw уже построен, на самом деле там еще файлы .dll/lib открыты и недописаны и слинковаться с ними все еще нельзя, еще несколько секунд.
Тут же вот какая беда: есть	Тут же вот какая беда: есть оптимальное поведение (и в данном случае это было бы "закэшировать в регистре"), а есть "рассчитанное на плохую ситуацию". Я готов принять, что по-умолчанию оно будет "рассчитано на дурака", если какое-то количество многопоточных ошибок (коих много в жизни) будет таким способом заметено под ковер, то и слава богу, они не проявятся в реальной жизни, всем будет легче. Но я хочу иметь возможность это отключить. Схожая история уже обсуждалась тут: http://blog.lexa.ru/2010/12/27/o_stepennoi_funktsii_openmp_i_prochikh_gr... В VS2010 в OpenMP добавили спинлок, для синхронизации после завершения всех тредов. Отчего стало больно в тех случаях, когда worker-ы мелкие, оверхед большой. Зато какое-то количество ошибок исчезло. Интел его тоже добавил, но сделал регулируемым.
volatile - это re-read перед	volatile - это re-read перед каждым обращением, про write не написано :) Но полностью разделяю негодование!
Я прошу прощения, что вопрос, может, на уровне чайника. Я с	Я прошу прощения, что вопрос, может, на уровне чайника. Я скачал LibRaw-0.14.0-demosaic-packs-GPL2-GPL3-Win32.zip Переписал в папку D:\Projects\LibRaw\ Открыл файл LibRaw.sln, он открылся. Попробовал построить, и тут оп. 4>LINK : fatal error LNK1181: не удается открыть входной файл "libraw.lib" Ну, попытался построить второй раз - оно строит, хотя не всё. У меня такое чувство, что там что-то не то с зависимостями, нет? То есть, к тому моменту когда ему нужно dcraw_emu.exe строить, у него ещё нет lib.
Интел научился только если он видит весь контекст исполнения	Интел научился только если он видит весь контекст исполнения. Он много что в таком случае умеет, например узнать что данные получены через _mm_malloc и можно их грузить movaps, а не movups, много такого хорошего он умеет. Но в реальной жизни, когда объектник компилируются, чтобы лечь в .DLL, которую будет неизвестно кто и неизвестно какими данными, в данном примере получается одинаковое говно. И мой вопрос именно про то, как его избежать, сказав компилятору петушиное слово.
Синхронизации нужны если несколько потоков пишут в одну loca	Синхронизации нужны если несколько потоков пишут в одну location. Это без вопросов. А если второй поток только читает - то он получит какое-то значение. Так как без синхронизации - неизвестно в какую итерацию цикла он попадет, то любое значение ему подойдет.
А как это сделать для переменной - члена класса?	А как это сделать для переменной - члена класса?
Именно! Включая здравый смысл	Именно! Включая здравый смысл - я ожидаю точки сброса в память именно на границах функций, плюс еще атомиков (которые могут не функциями быть, а спецмакросами). Если мне зачем-то нужен постоянный сброс из регистра память - ну алле, в стандарте для этого уже 100 лет, как придумано отличное слово volatile. Но нет - искуственный интеллект зачем-то делает неявный volatile для члена класса.
про "что сказал"	Явного модификатора volatile на этом члене класса простите, нету. В стандарте ничего про гарантии доступности из соседних тредов, простите, нету. Там вообще слова "тред", простите, нету. Многопоточные ошибки такие фокусы, простите, не исправляют. А наоборот, заметают под ковер и усложняют поимку и починку. Поэтому, считаю, осознанно реализовывать такое поведение, аргументируя его заботой о тредах, это где-то между глупостью и вредительством. Я ни разу не говорил компилятору, что переменная volatile, и я хочу новое значение в памяти немедленно после каждой операции. Компилятор делает НЕ то, что я ему сказал!
Может везде явно ему намекать чтобы он переменную в регистре	Может везде явно ему намекать чтобы он переменную в регистре держал. И будет как бы явный не volatile. А компилятор уже либо сможет регистр использовать, либо нет.
В смысле, тогда эти неявные volatile и не нужны совсем.	В смысле, тогда эти неявные volatile и не нужны совсем.
вот именно "частично". Я вот другого не понимаю если не по	вот именно "частично". Я вот другого не понимаю если не пользоваться примитивами синхронизации (включая atomic функции) ведь ничего работать сейчас не будет. А если пользоваться, то всё будет хорошо, главное чтобы компилятор сбрасывал в пямять данные перед вызовами и возвратами функций.
Ну вот интел научился. Хотя я кажись в своих экспериментах н	Ну вот интел научился. Хотя я кажись в своих экспериментах несколько раз получил совершенно обратный результат - интел (девятый?) позорно облажался, а мелкософт выступил очень хорошо. Я тогда собственно бросил упражняться с компиляторами, решил что мелкософт - good enough for everybody, а что не гуд - руками перепишем.
Может не научились, а наоборот? Ну типа кэши сейчас быстрые	Может не научились, а наоборот? Ну типа кэши сейчас быстрые и т.д. если переменных не много, можно не париться, процессор сам внутри сделает?)
А кто научился? Я попробовал три компилятора, которые были	А кто научился? Я попробовал три компилятора, которые были на винде - все три ведут себя одинаково (с оговоркой про Intel, который во многом подобном был замечен и ранее, например он некоторые мои бенчмарки оптимизировал до полного исчезновения т.к. видел что результат не используется).
Да, по идее первый код - это именно volatile т.к. оно еще и	Да, по идее первый код - это именно volatile т.к. оно еще и перечитывает на каждой итерации. И все будет работать по меньшей мере частично т.к. процессоры/ядра обмениваются информацией о протухших адресах в кэше и re-read будет, как минимум, читать из памяти. Когда кэш сбрасывается - я никогда ранее не задумывался, оказывается есть инструкции и для целого кэша и для отдельного адреса....

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

Pages