Выростет не только зарплата, но и процент кредита. Посмотрите свой договор, там должен быть пункт об изменении процента.
К сожалению это игра где заемщик всегда проигрывает.
Уффф. Наверное да. Меня больше интересовали возможные последствия именно для случая массивов. Многопоточное приложение с общими данными это обыденность, причем иногда спрятанная за фасадом того или иного тулкита или библиотеки.
Здесь дело, в общем-то не в разрешении. Во-первых непонятные места нужно обсуждать с автором, и во-вторых по истечении времени может всякое в голову приходить.
ИМХО такой труд всегда будет интересен, но если будет доведен до конца. Еще я бы спросил списаляся по этому поводу с самим Ульрихом, и внимательно посмотрел комменты на lwn.net.
Эх, описка :(, надо читать вместо кешировать — буферизовать. Если буферизовать записи от многих операций, то создается условие когда результат уже есть а еще недоступен. В многопроцессорной системе другой проц может считать старые данные при наличии новых. Явный случай гонки. Но это теоретизирование.
>> Эксперимент хоть и грязный, но характерную особенность snooping-кешей показывает.
Ого, это много глубже чем мне хотелось бы залезать :). Хотя главное будет исполнение останавливаться если обнаружена некогерентность или нет, ммм где-то в глубине шевелются воспоминания о том что может и не будет.
>> Если не пытаться…
Если честно, идея инкрементировать одно и тоже слово мне не нравится, потому как, если отбросить атомарные операции, это таки ошибка. Другое дело — ограничить область памяти до одной линейки. Тут и синхронизация мало влиять должна.
>> Со скремблером идея неплоха, только сделайте её быстрее…
Спасибо ;) Ускорить можно, но на это надо потратить несколько часов, ибо последний раз я такую задачу делал лет 10 назад. Как-то мало времени.
>> Да, но у в приведённых программах нет же зависимостей write-after-read в разные ячейки памяти…
Ну да, зависимостей нет. Однако шина чтения/записи одна и поэтому две операции с памятью параллельно невозможны. Причем, записи скорее всего в одну линейку кеша, кешировать запись нельзя, иначе можно получить гонку.
Здесь более интересный вопрос в том есть у коры свой кеш или нет, вот это для меня уже загадка.
>> И какие цифирьки получились? Интересно же.
За выводами будут таблицы. Первые две это для случая чтения-инкремент-запись. Вторая пара для случая чтение-скремблер-запись без оптимизации. Третья пара для случая чтение-скремблер-запись с оптимизацией -O2. Длина слова в битах.
В принципе Вы правы. В случае скремблера операция с данными слишком долгая, поэтому эффект мало заметен, особенно после оптимизации.
>> Тест вобщем-то не совсем корректный, imho.
Да я, в общем-то, абсолютной корректности и не добивался. Главное было понять проявится эффект или нет. С большой долей уверенности можно сказать что проявляется. Тема слишком тонкая и не такая простая для тестов.
В основе моих тестов лежит идея о том, чтобы данные постоянно обновлялись, что приводило бы к постоянным синхронизациям и, как следствие, к столкновениям.
>>Потому что нити запускаются не одновоременно
Да, с синхронизацией скорее всего есть проблемы, но это вопрос очень тонкий. Я бы сказал что точной синхронизации можно добиться только для моделей CPU, но толку от таких тестов мало, ведь никто не отрицает наличие эффекта.
>> scramble работает не за такт
Да уж не самый удачный тест, но причина его использования упомянута в тексте.
>> да ещё и процессоры не в одну линию кэша долбятся, а последовательно в разные.
В принципе, для первого теста для случая 1 и 4-х байт должный попадать на одну линию.
>> В Core 2 Duo синхронизация кэшей…
Должен признать опечатку. Процессор Core 2 Quad, но судя по всему там тоже линейки по 64 байта.
Вообще тема синхронизации достаточно сложная. С учетом ассоциативности время на определение наличия в кеше должно быть меньше одного такта (скорее всего меньше 1/2 такта). Синхронизация кешей зависит от особенностей внутренней шины, точнее арбитра шины, и скорее всего будет больше заявленных 3 тактов.
Вообще второй тест какой-то неудачный получился.
>> Процессоры же у нас все из себя out-of-order и суперскалярные.
Главное правило при проектировании CPU: внутри cpu может происходить все как угодно, но программа должна исполняться в том порядке в котором она была записана в памяти. Т.е. в любом случае процессор делает работу так как если бы за такт выполнялась одна комманда и не более. Иначе получится что программы не будут давать ожидаемого результата. Если вам будет интересна эта тема, то лучше почитать отчеты WRL 1989-1991 годов по Альфе.
В случае суперскаляра декодер исследует код на предмет возможного распараллеливания с учетом возможных зависимостей данных, хотя в большей степени эта операция касется условных переходов. Операции с памятью не относятся к распараллеливаемым, в силу возможных зависимостей данных. В принципе, то что вы пишите должен сделать оптимизирующей компилятор, хотя что вполучится в итоге лично для меня загадка.
В интелях еще 10 лет назад в у декодеров были буферы 256к. Так что код, скорее всего и из кеша только один раз выбирался, но это слишком тонкая материя, хотя нити могут мигрировать по ядрам…
>> Теоретически, проседание по скорости должно наблюдаться и в том случае, если вы вместо u_int64_t во втором случае тоже байты будете использовать.
Хмм… Так тесты и для разной длины слов проводились. В программах менялось MTYPE на нужное значение. Если вы об этом.
Лично меня больше греет то, что продукт кому-то нужен и кому-то помогает. Попытка вечно жить за счет чего-то одного затупляет. Но это не абсолютно не значит что все надо делать бесплатно, кушать-то хоцца, да и творения других тоже надо оценить ;).
Спасибо.
Однако в чистом виде такое право вряд ли будет реализовано. Потому как и образование базируется на опыте других, их ведь никто не будет спрашивать, и продукт может быть национальным достоянием или от него может зависеть что-то важное и т.д. Иначе говоря произвол общества над личностью.
Лично мне кажется главное это то что автор или коллектив пользуется опытом многих поколений, так что мне кажется надо всегда идти на компромис. Если денег хватает зачем доводить все до абсурда.
Согласен. Основная проблема заключается в тестовых алгоритмах. Как-то не придумался вариант с одной стороны полезный, с другой стороны мало искажающий суть проблемы.
Хотя еще не вечер, будем искать.
Авторство всегда гарантировано. Гарантий дохода никто и никогда не дает. Почитайте про равновесие Неша (Nash equilibrium), дружно жить куда лучше. Вы ведь не с пустого места начинаете свою работу, многие из тех кто заложили основы современной науки ничего так и не получили.
«Если корпорация нарушает Ваши права ...» Стандартный сценарий. Вы делете какую-то суперштучку, получает патенты, регистрации и т.д. Корпорация А хочет эту суперштучку дешево, у них есть много патентов в той же области, и подает на вас в суд по нарушению (ваш патент ничего не нарушает!!!!). Допустим у вас стартап с долгом в $1млн и текущими доходами $300к в год. У корпорации бюджет юр отдела $3млн в год. Результат — вас задавили деньгами, патент продан и дай бог если все долги погашены. Вот это и есть «давят».
1. Боюсь нарваться на — но достойно ли качество поддержки? Для примера, в структуре доходов катерпиллера подержка — 60%!
"… поступил сигнал об отмене решения о покупке десятка лицензий ..."
Хмм… у вас отказались купить или решили не продавать? Мне кажется обе эти ситуации решаемы и без потерь.
К сожалению это игра где заемщик всегда проигрывает.
Ого, это много глубже чем мне хотелось бы залезать :). Хотя главное будет исполнение останавливаться если обнаружена некогерентность или нет, ммм где-то в глубине шевелются воспоминания о том что может и не будет.
>> Если не пытаться…
Если честно, идея инкрементировать одно и тоже слово мне не нравится, потому как, если отбросить атомарные операции, это таки ошибка. Другое дело — ограничить область памяти до одной линейки. Тут и синхронизация мало влиять должна.
>> Со скремблером идея неплоха, только сделайте её быстрее…
Спасибо ;) Ускорить можно, но на это надо потратить несколько часов, ибо последний раз я такую задачу делал лет 10 назад. Как-то мало времени.
Эх, пробую, но я как-то мало силен в верстке.
Ну да, зависимостей нет. Однако шина чтения/записи одна и поэтому две операции с памятью параллельно невозможны. Причем, записи скорее всего в одну линейку кеша, кешировать запись нельзя, иначе можно получить гонку.
Здесь более интересный вопрос в том есть у коры свой кеш или нет, вот это для меня уже загадка.
>> И какие цифирьки получились? Интересно же.
За выводами будут таблицы. Первые две это для случая чтения-инкремент-запись. Вторая пара для случая чтение-скремблер-запись без оптимизации. Третья пара для случая чтение-скремблер-запись с оптимизацией -O2. Длина слова в битах.
В принципе Вы правы. В случае скремблера операция с данными слишком долгая, поэтому эффект мало заметен, особенно после оптимизации.
Да я, в общем-то, абсолютной корректности и не добивался. Главное было понять проявится эффект или нет. С большой долей уверенности можно сказать что проявляется. Тема слишком тонкая и не такая простая для тестов.
В основе моих тестов лежит идея о том, чтобы данные постоянно обновлялись, что приводило бы к постоянным синхронизациям и, как следствие, к столкновениям.
>>Потому что нити запускаются не одновоременно
Да, с синхронизацией скорее всего есть проблемы, но это вопрос очень тонкий. Я бы сказал что точной синхронизации можно добиться только для моделей CPU, но толку от таких тестов мало, ведь никто не отрицает наличие эффекта.
>> scramble работает не за такт
Да уж не самый удачный тест, но причина его использования упомянута в тексте.
>> да ещё и процессоры не в одну линию кэша долбятся, а последовательно в разные.
В принципе, для первого теста для случая 1 и 4-х байт должный попадать на одну линию.
>> В Core 2 Duo синхронизация кэшей…
Должен признать опечатку. Процессор Core 2 Quad, но судя по всему там тоже линейки по 64 байта.
Вообще тема синхронизации достаточно сложная. С учетом ассоциативности время на определение наличия в кеше должно быть меньше одного такта (скорее всего меньше 1/2 такта). Синхронизация кешей зависит от особенностей внутренней шины, точнее арбитра шины, и скорее всего будет больше заявленных 3 тактов.
Вообще второй тест какой-то неудачный получился.
>> Процессоры же у нас все из себя out-of-order и суперскалярные.
Главное правило при проектировании CPU: внутри cpu может происходить все как угодно, но программа должна исполняться в том порядке в котором она была записана в памяти. Т.е. в любом случае процессор делает работу так как если бы за такт выполнялась одна комманда и не более. Иначе получится что программы не будут давать ожидаемого результата. Если вам будет интересна эта тема, то лучше почитать отчеты WRL 1989-1991 годов по Альфе.
В случае суперскаляра декодер исследует код на предмет возможного распараллеливания с учетом возможных зависимостей данных, хотя в большей степени эта операция касется условных переходов. Операции с памятью не относятся к распараллеливаемым, в силу возможных зависимостей данных. В принципе, то что вы пишите должен сделать оптимизирующей компилятор, хотя что вполучится в итоге лично для меня загадка.
В интелях еще 10 лет назад в у декодеров были буферы 256к. Так что код, скорее всего и из кеша только один раз выбирался, но это слишком тонкая материя, хотя нити могут мигрировать по ядрам…
>> Теоретически, проседание по скорости должно наблюдаться и в том случае, если вы вместо u_int64_t во втором случае тоже байты будете использовать.
Хмм… Так тесты и для разной длины слов проводились. В программах менялось MTYPE на нужное значение. Если вы об этом.
Уф. По этой теме можно писать много и вдумчиво.
Спасибо.
Однако в чистом виде такое право вряд ли будет реализовано. Потому как и образование базируется на опыте других, их ведь никто не будет спрашивать, и продукт может быть национальным достоянием или от него может зависеть что-то важное и т.д. Иначе говоря произвол общества над личностью.
Лично мне кажется главное это то что автор или коллектив пользуется опытом многих поколений, так что мне кажется надо всегда идти на компромис. Если денег хватает зачем доводить все до абсурда.
Хотя еще не вечер, будем искать.
Насколько я знаю, никакое законодательство не может требовать от граждан покупать.
О каком нарушеннии здесь идет речь? И о каких правах тогда идет речь? Извините, но я не понимаю.
Или вы хотите сказать что автору может не нравиться, когда пользователь получает его продукт не в глянцевой коробке с неадекватными картинками ( ;) )?
Да уж, верно говорят Китайцам лучше продавать сразу и очень дорого.
«Если корпорация нарушает Ваши права ...» Стандартный сценарий. Вы делете какую-то суперштучку, получает патенты, регистрации и т.д. Корпорация А хочет эту суперштучку дешево, у них есть много патентов в той же области, и подает на вас в суд по нарушению (ваш патент ничего не нарушает!!!!). Допустим у вас стартап с долгом в $1млн и текущими доходами $300к в год. У корпорации бюджет юр отдела $3млн в год. Результат — вас задавили деньгами, патент продан и дай бог если все долги погашены. Вот это и есть «давят».
"… поступил сигнал об отмене решения о покупке десятка лицензий ..."
Хмм… у вас отказались купить или решили не продавать? Мне кажется обе эти ситуации решаемы и без потерь.