Глеб Смирнов (glebius@) добавил (http://lists.freebsd.org/pipermail/freebsd-arch/2013-April/0...) в ядро FreeBSD 10-CURRENT новый API для работы со счётчиками — counter(9). Счётчики являются (http://bu7cher.blogspot.ru/2013/04/pcpu.html) частью инструментария сбора статистики и телеметрии во время работы ядра и системных компонентов и представляют собой структуры данных в оперативной памяти, значения в которых изменяются при наступлении тех или иных событий. К примеру, счётчики для подсчёта полученных и отброшенных сетевых пакетов, счётчик числа обнаруженных некорректных данных в подсистеме ввода-вывода и т.д..В многопроцессорной многопоточной системе с большим количеством счётчиков возникает проблема конкуренции вычислительных потоков за монопольный доступ и корректное изменение значения счётчика. Обычное решение этой проблемы — монитор объекта счётчика через операцию блокировки шины памяти (atomic(9)) и предоставление монопольного доступа к счётчику одному из конкурирующих потоков для его инкремента. Но при таком способе ухудшается быстродействие в многозадачной среде: сбрасываются кэши процессорных ядер из-за недействительных значений счётчика, находящихся в их кэшах, с последующей перезагрузкой актуального значения счётчика из оперативной памяти в кэш процессора.
Новый API по-своему решает проблему актуализации счётчиков для всех заинтересованных потоков выполнения. Так, для каждого ядра процессора выделяется собственная область памяти, а структуры данных счётчиков мультиплицируются в эти области и не перекрывают друг друга. Теперь каждому ядру соответствует своя копия определённого счётчика, а каждое ядро изменяет только свою структуру данных счётчиков. Блокировка шины памяти для монопольного доступа потоков к счётчику больше не нужна. Чтобы обновить счётчик вычислительному потоку, ему нужно получить адрес счётчика в памяти ядра, на котором он выполняется, и произвести его изменение.
Для того, чтобы в это время контекст не мигрировал на другое ядро, используются критические секции (не на всех архитектурах это необходимо и часто удаётся избежать использования критических секций). В частности, на основной архитектуре FreeBSD — amd64 — обновление счётчика осуществляется в одну процессорную инструкцию! Для считывания значение счётчика, нужно просто сложить значения копий счётчика со всех ядер. Ну и объём памяти, занимаемый счётчиком, конечно же стал в несколько раз больше — в прямой зависимости от числа ядер процессоров.
Результаты:- В ряде тестов новые счётчики показывают повышение производительности примерно на 63% по сравнению с обычной операцией инкремента, но при этом нет потерь данных, а обычный инкремент теряет 98% данных;- В сравнении с атомарными инкрементами новые счётчики в 22 раза быстрее;- На реальных тестах по приёму сетевого трафика замена счётчиков IP-статистики приводит к снижению нагрузки на CPU примерно на 50%.
URL: http://bu7cher.blogspot.ru/2013/04/pcpu.html
Новость: http://www.opennet.me/opennews/art.shtml?num=36669
http://zet-news.ru/img/userfiles/images/0000ebae.jpgВот.
Не ты ли прыгать от радости должен что во фре что-то быстрее стало?
а тесты похороникса все равно напишут что тормозит ))))
в bsd главое ядра и не любит больше потоков чем цпу,
линукс любит много потоков и не любит от количества цпу
Вывод: в бзде не осилили написать нормальный планировщик процессорного времени.Хотя в форониксовых бенчах факапы обычно потому что или компилится античным gcc 4.2, который по оптимизации vs 4.7 сильно проигрывает, или того хуже шлангом, который не только погано оптимизирует но и OpenMP хронически не умеет. А это сразу слив в несколько раз на пакетах типа GraphicsMagic'а и подобных, использующих OpenMP.
OpenMP костыль, предпочитаем векторизацию cpp кодаhttp://ru.wikipedia.org/wiki/Векторизация%20(параллельные%20вычисления)
> OpenMP костыль, предпочитаем векторизацию cpp кодаВот только в шланге 3.3 грозились таки его сделать. Ибо без него феерический слив в куче реально существующих программ. Дайте угадаю, он после этого сразу перестанет быть костылем, да? :).
> http://ru.wikipedia.org/wiki/Векторизация%20(параллельные%20вычисления)
Вику читать умеете. Малацца, возьмите с полки пирожок.
> Вывод: в бзде не осилили написать нормальный планировщик процессорного времени.Зато в FreeBSD нет лагов курсора мышки при длительном копировании файлов с одного носителя на другой. Воспроизведение Full HD фильмов не нарушается, если в текстовой консоли идёт компиляция в несколько потоков.
> Хотя в форониксовых бенчах факапы обычно потому что или компилится античным gcc
> 4.2, который по оптимизации vs 4.7 сильно проигрывает,LLVM/Clang 3.2 в системе FreeBSD 9.1 производит код, который по скорости исполнения сравнялся с GCC 4.6. Кстати, во FreeBSD 8.x его можно поставить из порта, если нужно собрать приложения.
> или того хуже шлангом, который не только погано оптимизирует но и OpenMP хронически не умеет.
Много ли где поддерживается OpenMP? Перечислите ПО, где оно жизненно необходимо.
> А это сразу слив в несколько раз на пакетах типа GraphicsMagic'а и подобных, использующих OpenMP.
Ссылку?
> Зато в FreeBSD нет лагов курсора мышки при длительном копировании файлов с одного носителя
> на другой. Воспроизведение Full HD фильмов не нарушается, если в текстовой консоли идёт
> компиляция в несколько потоков.Давно линух-то видел?
make -j128 & mplayer Private-17_1920x1080.mkv, и ещё дропбокс чёй-то в фоне синхронзирует.
>> Зато в FreeBSD нет лагов курсора мышки при длительном копировании файлов с одного носителя
>> на другой. Воспроизведение Full HD фильмов не нарушается, если в текстовой консоли идёт
>> компиляция в несколько потоков.
> Давно линух-то видел?Каждый день вижу.
> make -j128 & mplayer Private-17_1920x1080.mkv, и ещё дропбокс чёй-то в фоне синхронзирует.
Повтори это на компе 5 летней давности с одной из последних стабильных версий ядра Linux — расскажешь.
>Каждый день вижу.Интересно где? На работе, где у тебя везде windows, или дома, где у тебя по слухам freeBSD
ты даже не в курсе, что для такого параметра нужно ещё поболе памяти.
так что будет работать и на Core 2 пятилетней давности. ну и к чему было сказано про "с одной из последних стабильных версий ядра Linux"? наверное, потому что ты - теоретик и неадекватный фанатик BSD. У меня среди подопечных где-то Mobile Celeron есть (тактовая 1.2GHz), на котором 3.8-6 ядро. напомнить год, когда эти процессоры делали?
>Повтори это на компе 5 летней давности с одной из последних стабильных версий ядра Linux — расскажешь.Acer Extensa 5210 - T5600@1.83, 2 гига оперы и хард на 5400.
Повторил - не тормозит.>Каждый день вижу.
На скриншотах?
>LLVM/Clang 3.2 в системе FreeBSD 9.1 производит код, который по скорости исполнения сравнялся с GCC 4.6
Странно. А на остальных системах (не FreeBSD) шланг сливает процентов на 10-15 в однопотоке. И это не считая мест, где оно может в 2-3 раза более медленный код выдавать.
> Повтори это на компе 5 летней давности ...# dmidecode | less
Handle 0x0000, DMI type 0, 20 bytes
BIOS Information
Vendor: Phoenix Technologies Ltd.
Version: 2004Q3 # чорт, почти 9-летней давности, ...
Release Date: 11/18/2008
Address: 0xE69B0
Runtime Size: 104016 bytes
ROM Size: 1024 kBSystem Information
Manufacturer: TYAN Computer Corp.
Product Name: S2895
Version: TYAN Thunder K8WE S2895
Serial Number: 0123456789
UUID: Not Settable
Wake-up Type: Power Switch
...
> ... с одной из последних стабильных версий ядра Linux — расскажешь.# uname -a
Linux suse64 3.2.43-plx #2 SMP PREEMPT RT Thu Apr 11 01:17:28 MSK 2013 x86_64 x86_64 x86_64 GNU/Linux---
Скажу боле, до этого у меня стоят Adaptec ASC-29320 и все винты на Ultra320 SCSI,
любимый всеми троллями баг #12309 вообще никак непроявлялся. И все адекватные уже
знают, что это косяк SATA архитектуры, тут ни ось, ни производитель ничё сделать
не могут. Ну увеличели make -j до 128, ну и чё?!Можно так же потроллить на предмет, "Вы лузеры", Linx + SCSI SSD, со 128Gb RAM
и make -j10000 в лёгкую работает, Вывод: BSD - говно!".
> Зато в FreeBSD нет лагов курсора мышки при длительном копировании файлов с
> одного носителя на другой. Воспроизведение Full HD фильмов не нарушается, если
> в текстовой консоли идёт компиляция в несколько потоков.Так у меня и в линуксе так же.
> LLVM/Clang 3.2 в системе FreeBSD 9.1 производит код, который по скорости исполнения
> сравнялся с GCC 4.6.Бенчи на форониксе этот тезис в очередной раз не подтвердили. Особенно фееричный слив на софте с OpenMP, там буквально по числу ядер просёр. В шланге 3.3 вроде как грозились его все-таки реализовать, но сейчас то у вас попа голая. Да и в целом по оптимизации шланг явно хуже.
> Кстати, во FreeBSD 8.x его можно поставить из порта, если нужно собрать приложения.
А кому кроме сектантов нужна лишняя возня?
>> или того хуже шлангом, который не только погано оптимизирует но и OpenMP хронически не умеет.
> Много ли где поддерживается OpenMP? Перечислите ПО, где оно жизненно необходимо.Смотря что понимать под жизненно необходимо. Без него ряд софта просто будет в эн раз тормознее, по числу ядер.
>> А это сразу слив в несколько раз на пакетах типа GraphicsMagic'а и подобных,
>> использующих OpenMP.
> Ссылку?Фороникс. И его бенчи. И коменты к ним, где какие-то клоуны аж просили не делать :) бенчи с openmp xD. А то слив, видите ли.
> Бенчи на форониксе этот тезис в очередной раз не подтвердили. Особенно фееричный слив на софте с OpenMPХорошие бенчи. Берём софт заточеный под OpenMP и сравниваем. Собраный без OpenMP - медленнее, ибо в один поток. Аплодисменты идиотов идиотам.
>Хотя в форониксовых бенчах факапы обычно потому что или компилится античным gcc 4.2, который по оптимизации vs 4.7 сильно проигрывает, или того хуже шлангом, который не только погано оптимизирует но и OpenMP хронически не умеет.Тем не менее БЗДЯ 9.1 STABLE собранная clang 3.2 все- таки процентов на 10 как минимум шустрее нежели собранная gcc 4.2.
Плюс у шланга есть все шансы догнать gcc уже в обозримом будущем.Да, насчет OpenMP. Я конечно не обравдываю шланг, но все же насколько часто В РЕАЛЬНЫХ приложениях OpenMP используется?
>> В РЕАЛЬНЫХ приложениях OpenMP используется?ImageMagick только))
Позитивно :)
Странно только, что такое положение дел так долго терпели.
Кхм, в Линуксе per-cpu counters уже черт знает сколько существуют. Фря конечно впереди планеты всей.
> впереди планеты всей.Да они такие инноваторы что даже апач с яхой заманались. Хотя этих древних зубров вообще сложно на что либо сподвигнуть - они толстокожие неимоверно.
>> впереди планеты всей.
> Да они такие инноваторы что даже апач с яхой заманались. Хотя этих
> древних зубров вообще сложно на что либо сподвигнуть - они толстокожие
> неимоверно.В каком году, ась? Не в тех ли годах, когда началась массовая истерия олинуксячивания всех и вся? Начиная, примерно, с 2003-2006 годах, когда Linux после неоднократных миллионных вливаний IBM был наконец-то готов к продакшену с классической журналируемой Ext3 (ага — после двух или трёх лет внедрения журнала в Ext2), а FreeBSD с экспериментальной поддержкой SMP в ULE и, опять же, экспериментальной UFS2, созданной на университетские гранты, была ещё не готова к распределённым нагрузкам?
> ULE и, опять же, экспериментальной UFS2, созданной на университетские гранты,Этот ваш экспериментальный UFS2 на самом деле экскрементальный. Создан из окаменелых экскрементов мамонта - древнючего UFS. И капитально его переделывать никто не стал - бздоиды как обычно заявили что "на это нет ресурсов". Так что нехай будет вот таким вот уродцем внутрях. Кроме всего прочего по этой причине у него отстойная производительность на многих ворклоадах. Почему-то как ни бенч фороникса с UFS2, так грохот кирпичей бздоидов слышен за километры.
>> ULE и, опять же, экспериментальной UFS2, созданной на университетские гранты,
> Этот ваш экспериментальный UFS2 на самом деле экскрементальный. Создан из окаменелых экскрементов мамонта - древнючего UFS. И капитально его переделывать никто не стал
> - бздоиды как обычно заявили что "на это нет ресурсов"."Ext2 + журналирование => Ext3 + экстенты => Ext4" — тоже историю надо знать.
> Так что нехай будет вот таким вот уродцем внутрях. Кроме всего прочего
> по этой причине у него отстойная производительность на многих ворклоадах.На каких конкретно?
> Почему-то как ни бенч фороникса с UFS2, так грохот кирпичей бздоидов слышен за километры.
Последний раз они тестировали быстродействие классических ФС где-то в 2010 году, если не ошибаюсь. UFS2 с SU+J в тесты не попала.
ну, это оттого, что поклонники фри, вместо того чтобы кодить, выискивают в Сети код, который называют говном. а после чего срутся на 100+ форумных веток с обиженным автором говнокода, да.;)
Я то думал, почему не растет скорость tcp при увеличении процессоров.
бздишникам подарили много процессорную тачку? :)
=====
ping svn0.us-west.FreeBSD.org
ping svn0.us-east.FreeBSD.org
======
svn co http://svn0.us-east.FreeBSD.org/base/head /usr/src
или
svn co http://ping svn0.us-west.FreeBSD.org/base/head /usr/src=====
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/sv...
Никто случаем не знает, что за тулза использовалась в исходном письма для вывода статистики? Тоже такую хочу.
Если ты про это письмо http://lists.freebsd.org/pipermail/freebsd-arch/2013-April/0...То это ministat(1) - http://svnweb.freebsd.org/base/head/usr.bin/ministat/
Ну и в репах Debian я её точно видел.
и как задействовать это в ядре ?
sysctl ?
Это внутренний фреймворк ядра, задействовать его должны разработчики. Глеб вот переводит сетевой стек на его использование.
жаль что опеннет всетаки превратился в клоаку по образу и подобию лора. переименовать в линукснет и оставить их тут с Богом, с риторикой убунту вс генту... детский сад, ясельная группа..
Как говорится, "каков поп, таков и приход"