5 лет назад и 10 лет назад я мог бы написать похожий пост, и сейчас все еще согласен с автором по всем пунктам. Хотя конечно сильно отстаю по пунктам 15-16.
видел в работе vxworks, различные linux'ы с RT patch'ами и без (если без, то RT код дописывают в ISR от LAPIC или от PCIe устройства), win ce, tenasys intime, патчи к винде от Beckhoff или codesys, bare metal.
Так тоже можно, конечно, если бы goto would not be considered harmful :)
Просто в голове по дефолту представляю рекурсивный вид, т.к. последние несколько недель писал на clojure.
Проблема, которую вы описываете, играет существенную роль для систем с общим LLC, на которых на разных ядрах исполняются RT и GPOS, с или без виртуализации. Если цикл для RT системы порядка сотен микросекунд с толерантностью в десятки микросекунд, вытеснения данных RT процесса из LLC действительно будет критичным.
В ARM есть Cache lock down, которые это решает, в x86 (пока) нет.
+1, В Новой Зеландиии просто не претендовал на дополнительные баллы за диплом для PR, и все равно баллов хватило в свое время (2007 год, как сейчас не знаю)
2 копейки:
1. AES-NI уже был в Westmere.
2. Так же в SNB-EP (и вроде в Westmere-EP тоже, но насчет него не уверен) появилась TLB для гигабайтных страниц.
да, я бы тоже добавил к обычной critical_section optimistic_critical_section с HLE, и чтобы программист или компилятор/рантайм решали, какую выбрать, в зависимости от контеншна, величины, кода внутри.
1. У меня пока нет железки, так что не мерял. Плюс мы же вроде не имеем права публиковать бенчмарки до выхода железа. По идее если просто перекомпилять с HLE pthreads mutexes, и запустить что-то с большим количеством локов но низким контеншеном на EP или лучше EX будет очень хороший спидап.
2. Да, конечно, в случае сильно многопоточных приложений просто будет лучше скейлится. Но так как цена работы программиста давно уже больше цены процессорного времени, упрощение разработки многопоточного кода тоже хорошая мотивация.
3. Для программиста основная разница в том, что с критической секцией надо постоянно держать в голове, что при взаимодействии с другими локами возможен deadlock, в транзакции нет. Плюс если критическая секция возникла из-за того, что код внутри работает с разделяемой структурой (хэшом, массивом, списком) логично, что оптимистическое выполнение этого кода многими транзакциями одновременно будет часто быстрее, чем обычное сериализованное.
Фреймбуфер — один из сценариев, в котором на Sandy Bridge и последующих процессорах код копирования, реализованный на SSE4 будет существенно быстрее, чем на rep movs.
Вы спросили про бенчмарк, т.к. вы считаете, что мои даные и/или микро бенчмарк некорректны. Я был готов прислать исходник. Где здесь неуважение? Еще пара человек спросили, выслал и им.
Если для виндов не подходит, то для какой ОС? И кстати, что не так с пользователями, которые в числе прочих ОС пользуются и виндами?
Основной тезис моей статьи был, что давно rep movs был эффективным, потом появились гораздо лучшие SSE реализации, но недавно, по сути с Sandy Bridge и последующих, копирование при помощи rep mov, которое используется в ядре Linux и некоторых других продуктов(MSVC stdlib и тд) сравнялось по скорости с сложным SIMD кодом.
Из двух ваших комментариев, если я их правильно понял, следует противоположный тезис — ничего не изменилось, на процессорах Sandy Bridge, которые вышли примерно год назад, SIMD реализация копирования в 20 раз быстрее, чем rep movs.
Я свой бенчмарк (которым, по-вашему, ничего проверить нельзя) описал. Можно узнать подробности вашего? В вашем бенчмарке, где вы копируете картинку для последующего сжатия, у вас просто
memcpu(kartinka_dest, kartinka_src, kartinka_len_in_bytes);
или вы копируете как-то по линиям или еще как-то? Какого размера область памяти? Находится ли она уже в LLC?
Просто в голове по дефолту представляю рекурсивный вид, т.к. последние несколько недель писал на clojure.
{
//1,2,3
}
profile()
{
//4,5,6,
if (! надоело)
profile();
}
В ARM есть Cache lock down, которые это решает, в x86 (пока) нет.
Он конечно из Австралии приехал, но я его в НЗ видел.
1. AES-NI уже был в Westmere.
2. Так же в SNB-EP (и вроде в Westmere-EP тоже, но насчет него не уверен) появилась TLB для гигабайтных страниц.
2. Да, конечно, в случае сильно многопоточных приложений просто будет лучше скейлится. Но так как цена работы программиста давно уже больше цены процессорного времени, упрощение разработки многопоточного кода тоже хорошая мотивация.
3. Для программиста основная разница в том, что с критической секцией надо постоянно держать в голове, что при взаимодействии с другими локами возможен deadlock, в транзакции нет. Плюс если критическая секция возникла из-за того, что код внутри работает с разделяемой структурой (хэшом, массивом, списком) логично, что оптимистическое выполнение этого кода многими транзакциями одновременно будет часто быстрее, чем обычное сериализованное.
Надеюсь, STM.NET это поможет, и-или F# тоже.
Вы спросили про бенчмарк, т.к. вы считаете, что мои даные и/или микро бенчмарк некорректны. Я был готов прислать исходник. Где здесь неуважение? Еще пара человек спросили, выслал и им.
Если для виндов не подходит, то для какой ОС? И кстати, что не так с пользователями, которые в числе прочих ОС пользуются и виндами?
Основной тезис моей статьи был, что давно rep movs был эффективным, потом появились гораздо лучшие SSE реализации, но недавно, по сути с Sandy Bridge и последующих, копирование при помощи rep mov, которое используется в ядре Linux и некоторых других продуктов(MSVC stdlib и тд) сравнялось по скорости с сложным SIMD кодом.
Из двух ваших комментариев, если я их правильно понял, следует противоположный тезис — ничего не изменилось, на процессорах Sandy Bridge, которые вышли примерно год назад, SIMD реализация копирования в 20 раз быстрее, чем rep movs.
Я свой бенчмарк (которым, по-вашему, ничего проверить нельзя) описал. Можно узнать подробности вашего? В вашем бенчмарке, где вы копируете картинку для последующего сжатия, у вас просто
memcpu(kartinka_dest, kartinka_src, kartinka_len_in_bytes);
или вы копируете как-то по линиям или еще как-то? Какого размера область памяти? Находится ли она уже в LLC?
1 да.
2. не поможет, инфа 100%.