[jab]

Роутер будет корячится и слать icmp port unreachable. Что уже нарушает чистоту эксперимента.

Мне именно это и нужно. При icmplim=200 оверхедом можно пренебречь.

[nuclearcat]

Ну незнаю. Я посмотрел код под профайлером, там куча циклов процессора тратится на блокировки(в ядре, связанные с sendto() ) и прочую лабуду связанную с sendto

Учитывая что вызовы блокируемые, а среда передачи loopback (что уже предполагает от софта, что пакет не может находиться "в пути", а сразу принимается - это вообще херня получается. ИМХО не тест - а полная лабуда.

[jab]

Ну незнаю. Я посмотрел код под профайлером, там куча циклов процессора тратится на блокировки(в ядре, связанные с sendto() ) и прочую лабуду связанную с sendto

Учитывая что вызовы блокируемые, а среда передачи loopback (что уже предполагает от софта, что пакет не может находиться "в пути", а сразу принимается - это вообще херня получается. ИМХО не тест - а полная лабуда.

Вы вообще исходный постинг читали ? Похоже нет.

[jab]

 

После прочтения документации:

 

Ubench CPU: 2335618

Ubench MEM: 716019

--------------------

Ubench AVG: 1525818

 

[Latik]

to jab

Загляни сюда: http://unix.derkeiler.com/Mailing-Lists/Fr...7/msg00245.html

Интересный патчик для netblast

 

[jab]

 

Я ничего не измеряю netblast'ом, только генерю поток.

[IvanI]

Ubench CPU: 1849444

Ubench MEM: 571210

--------------------

Ubench AVG: 1210327

После прочтения документации:

 

Ubench CPU: 2335618

Ubench MEM: 716019

--------------------

Ubench AVG: 1525818

Шина 1333?

[jab]

 

Я более чем уверен в том, что на линухе ubench будет быстрее, как и всегда.

[nuclearcat]

А толку от этого?

 

[jab]

Ubench CPU: 2335618

Ubench MEM: 716019

--------------------

Ubench AVG: 1525818

Шина 1333?

gcc44 ( -march=k8 -msse -msse2 -msse3 ) + IPI_PREEMPTION

 

nat'у правда от этого ни жарко, ни холодно. :-)

 

А толку от этого?

Для меня есть толк - это мотивирует на тюнинг системы. :-) Для Вас - никакого толку.

[nuclearcat]

jab - затюнить и линукс можно, чем я обычно и занимаюсь. И эти опции всегда применяю. Хотя не совсем понятно почему k8.

В исходниках gcc, в config/i386/i386.c можно посмотреть чем они отличаются. Жаль i7 даже в cvs не присутствует.

 

В gcc 4.4 сделали много оптимизаций, что само по себе хорошо. Но я еще с "оптимизациями" в 4.3 не разобрался, они иногда так наоптимизируют, что потом по два дня ищешь, почему программа дурит. Последний прикол - sprintf перезатирает в одной сложной программе вместе с строкой назначения - один из аргументов.

 

msse3 и т.п. прекрасно работает и с core2. Из новых инструкций в i7 очень интересна отдельная, для crc32, для нее еще нет поддержки в gcc.

Интересно еще то, что L1/L2/L3 иерархически связаны, и меньше времени тратится на снупинг.

А ubench запущу, когда на работу припрусь, в понедельник.

 

[nuclearcat]

Вопрос к jab. Вы рассматривали DCA(Direct cache access) для x86_64 + некоторые интелевские карты?

[jab]

 

Насколько я понимаю для этого нужны Xeon'ы, которых у меня нет. :-)

[nuclearcat]

И серверные мамки с IO/AT + совместимые 1G адаптеры. Видимо нерентабельно даже попробовать....

[jab]

 

Ну на 10GE это имело бы хоть какой-то смысл... Суть же моих изысканий - дешевые молотилки пакетов. Тут я больше копаю в сторону GPGPU

networking.

[nuclearcat]

jab - я уже себе скоро мозоли на пальцах протру тоже по этому поводу. Ну не годиться GPU для этого... разве как отдельные ресурсоемкие функции.

 

Почему:

http://math.ut.ee/~uraes/openssl-gpu/ - даже на таких resource intensive операциях как шифрование толку мало. Плюс для достижения какого-то выигрыша нужна дорогая карта. Периферийные (PCI-E) ускорители имеют смысл только когда в них затолткнул данные и получил сразу полный результат на выходе. Если они могут сделать только часть операций, нужен быстрый обмен (и в плане скорости и в плане латентности) между CPU и GPU.

 

IMHO все заткнется на стыке PCI-E. Возможно что-то реально в случае набортного GPU от Интеля, который шарит основную память, но боюсь такое решение будет очень нестандартно. Мощность GPU в параллелизации достаточно простых вычислений (набор инструкций GPU очень ограничен), т.е. в лучшем случае это например распараллеливание проверки пакета на кучу рулесов, поиск соответствия в FIB, ну и NAT connection state... и то, как это сделать - фиг его знает. Если в userspace я это может и осилю, то в kernel - наврядли.

Например

http://ieeexplore.ieee.org/Xplore/login.js...thDecision=-203

[nag-f]

Ну на 10GE это имело бы хоть какой-то смысл... Суть же моих изысканий - дешевые молотилки пакетов. Тут я больше копаю в сторону GPGPU

networking.

GPGPU - для сетевых задач практически мало пригодны. Все преимущества многоядерности и SIMD съедает высокая латентность обращения к памяти (200-300 тактов) и маленький порядка 1-2К кеш. Имею практический опыт реализации вычислительных систем с использованием CUDA на базе G80, G200, и также Brook++ от ATI. Тут необходимо обращать внимание на специализированные под сетевые задачи архитектуры, а GPGPU оставьте в покое и не теряйте зря времени :)

Изменено 9 мая, 2009 пользователем nag-f

[nag-f]

jab - затюнить и линукс можно, чем я обычно и занимаюсь. И эти опции всегда применяю. Хотя не совсем понятно почему k8.

В исходниках gcc, в config/i386/i386.c можно посмотреть чем они отличаются. Жаль i7 даже в cvs не присутствует.

 

В gcc 4.4 сделали много оптимизаций, что само по себе хорошо. Но я еще с "оптимизациями" в 4.3 не разобрался, они иногда так наоптимизируют, что потом по два дня ищешь, почему программа дурит. Последний прикол - sprintf перезатирает в одной сложной программе вместе с строкой назначения - один из аргументов.

 

msse3 и т.п. прекрасно работает и с core2. Из новых инструкций в i7 очень интересна отдельная, для crc32, для нее еще нет поддержки в gcc.

Интересно еще то, что L1/L2/L3 иерархически связаны, и меньше времени тратится на снупинг.

А ubench запущу, когда на работу припрусь, в понедельник.

Ребята а вы в курсе вообще что в мире существует icc?

[jab]

 

Сейчас это все может и малопригодно. Но надо смотреть в перспективу. Вектор дальнейшего развития GPU очевиден. ( Быстрее, толще, кешастее )

Практический же смысл заключается не в использовании GPU как ускорителя, а разгрузка за счет него CPU и усиление обработки пакетов

при сохранении той же скорости.

[nag-f]

Сейчас это все может и малопригодно. Но надо смотреть в перспективу. Вектор дальнейшего развития GPU очевиден. ( Быстрее, толще, кешастее )

Практический же смысл заключается не в использовании GPU как ускорителя, а разгрузка за счет него CPU и усиление обработки пакетов

при сохранении той же скорости.

Вектор дальнейшего развития GPU, не ясен даже для таких монстров как AMD. Мое личное мнение, GPU будут вытеснены Larrabee-подобными арзитектурами. C выходом Larrabee в видеокартах, как в вычислителях отпадет необходимость. Переход графики на программируемые архитектуры обусловлены определенными тенденциями в области реалистичных алгоритмов синтеза изображений. Но это уже не тема для этого топика :)

 

Если говорить о NAT-е на 10G... в мире существует такая архитекстура, разработанная специально для сетевых задач. Плата с процессором стоит порядка 450$, набор инструментов для разработки - 20 000$

Изменено 9 мая, 2009 пользователем nag-f

[nuclearcat]

Ребята а вы в курсе вообще что в мире существует icc?

Во первых лицензия у него не очень удобная, во вторых отлаживать код тяжелее, в третьих бинарный он, в четвертых не очень любит других производителей по идеологии.

 

Сейчас это все может и малопригодно. Но надо смотреть в перспективу. Вектор дальнейшего развития GPU очевиден. ( Быстрее, толще, кешастее )

Практический же смысл заключается не в использовании GPU как ускорителя, а разгрузка за счет него CPU и усиление обработки пакетов

при сохранении той же скорости.

Пока GPU обращается к основному адресному пространству (и к CPU) через латентный и относительно медленный PCI-E - врядли в сетевых операциях от него будет толк.

[nag-f]

Ребята а вы в курсе вообще что в мире существует icc?

Во первых лицензия у него не очень удобная, во вторых отлаживать код тяжелее, в третьих бинарный он, в четвертых не очень любит других производителей по идеологии.

 

Сейчас это все может и малопригодно. Но надо смотреть в перспективу. Вектор дальнейшего развития GPU очевиден. ( Быстрее, толще, кешастее )

Практический же смысл заключается не в использовании GPU как ускорителя, а разгрузка за счет него CPU и усиление обработки пакетов

при сохранении той же скорости.

Пока GPU обращается к основному адресному пространству (и к CPU) через латентный и относительно медленный PCI-E - врядли в сетевых операциях от него будет толк.

Ну рассуждения это хорошо, но я скажу больше, что не то что обращение к памяти компьютера! (это тяжелый случай для карт), но даже при произвольном обращешнии к СОБСТВЕННОЙ DRAM на плате карты GPU имеют латентность 200-300 тактов!

 

Относительно icc. О каких производителях идет речь, если вы оптимизируете под Corei7? Зачем вам исходный код компилятора, вы часто исправляете исходный код компилятора? С отладкой никогда трудностей не возникало.

Изменено 9 мая, 2009 пользователем nag-f

[nuclearcat]

От ее собственной памяти в этих задачах толку мало. Да и можно маскировать эту латентность если подавать данные потоком и избегать branch misprediction.

 

Относительно icc. О каких производителях идет речь, если вы оптимизируете под Corei7? Зачем вам исходный код компилятора, вы часто исправляете исходный код компилятора? С отладкой никогда трудностей не возникало.

Для совсем уж синтетических тестов или уникального тазика пойдет конечно подобная оптимизация.

 

Но у меня большинство софта внедряется массово на разные платформы. Кроме того, не помню, собирается ли ядро нормально под icc.

[nag-f]

От ее собственной памяти в этих задачах толку мало. Да и можно маскировать эту латентность если подавать данные потоком и избегать branch misprediction.

Фух, это вы теоретически рассказываете, или практически реализовывали какие то примеры? Просто мне, как человеку реально разработавшему не одну вычислительную систему на базе GPU такое рассказывать не стоит. Разберитесь как "оно" работает, поэкспериментируйте... а потом расскажите что там можно маскировать и как избежать branch misprediction.

Изменено 9 мая, 2009 пользователем nag-f

[jab]

 

icc использовать в продакшине ? нет уж, увольте.