информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
За кого нас держат?Spanning Tree Protocol: недокументированное применение
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Sophos открывает Sandboxie 
 Большой вторник патчей от MS 
 И ещё раз об интернет-голосовании 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / software
Имя Пароль
ФОРУМ
все доски
FAQ
IRC
новые сообщения
site updates
guestbook
beginners
sysadmin
programming
operating systems
theory
web building
software
hardware
networking
law
hacking
gadgets
job
dnet
humor
miscellaneous
scrap
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Сравнительный benchmark в ответ на троллинг по теме bounded... 12.04.14 17:02  Число просмотров: 1603
Автор: leo <Леонид Юрьев> Статус: Elderman
<"чистая" ссылка>
Сравнительный benchmark в ответ на троллинг по теме bounded lockfree-очереди Дмитрия Вьюкова = http://www.1024cores.net/home/lock-free-algorithms/queues/bounded-mpmc-queue

Цифры ниже, кратко = "гиперконь" быстрее :)
Еще ниже некоторые отличия очереди в сравнении с конкурентами.

Running 1Hippeus queue-perfomance test, 300 seconds (CLOCK_PROCESS_CPUTIME_ID) foreach case...

one = (consumer + producer) * 1:
  boost::lockfree (direct,65534) 3.505 M/sec
  boost::lockfree (jack,dynamic) 3.589 M/sec
  1024cores (Dmitry Vyukov) 38.280 M/sec
  ring-single 20.425 M/sec
  ring-mytex 3.706 M/sec
  hippeus-single 42.779 M/sec
  hippeus-multi 27.787 M/sec

couple = (consumer + producer) * 2:
  boost::lockfree (direct,65534) 1.562 M/sec
  boost::lockfree (jack,dynamic) 1.428 M/sec
  1024cores (Dmitry Vyukov) 3.004 M/sec
  ring-mytex 0.151 M/sec
  hippeus-multi 6.071 M/sec

triple = (consumer + producer) * 3:
  boost::lockfree (direct,65534) 1.512 M/sec
  boost::lockfree (jack,dynamic) 1.544 M/sec
  1024cores (Dmitry Vyukov) 4.176 M/sec
  ring-mytex 0.142 M/sec
  hippeus-multi 7.443 M/sec

quad = (consumer + producer) * 4:
  boost::lockfree (direct,65534) 1.532 M/sec
  boost::lockfree (jack,dynamic) 1.537 M/sec
  1024cores (Dmitry Vyukov) 4.935 M/sec
  ring-mytex 0.152 M/sec
  hippeus-multi 7.684 M/sec

many = (consumer + producer) * 11:
  boost::lockfree (direct,65534) 1.606 M/sec
  boost::lockfree (jack,dynamic) 1.494 M/sec
  1024cores (Dmitry Vyukov) 4.166 M/sec
  ring-mytex 0.144 M/sec
  hippeus-multi 6.435 M/sec

crazy = (consumer + producer) * 64:
  boost::lockfree (direct,65534) 1.552 M/sec
  boost::lockfree (jack,dynamic) 1.519 M/sec
  1024cores (Dmitry Vyukov) 2.912 M/sec
  ring-mytex 0.145 M/sec
  hippeus-multi 6.212 M/sec

---

Если чуть более детально, то отличия от конкурентов такие:

1. hippeus быстрее всех при использовании XADD, но при этом теряет свойство lockfree, т.е. строго говоря становится ближе к obstruction-free.

2. однако, при двух писателях/читателях hippeus гарантирует lockfree и примерно вдвое быстрее очереди Вьюкова ивсехизвестных очередей.

3. hippeus не требует памяти для хранения sequence для каждого элемента, т.е. очередь из uintptr_t требует вдвое меньше памяти.

4. при работе в lockfree режиме hippeus-очередь также использует одну CAS-операцию, при этом скорость падает до очереди Вьюкова.

5. в сравнении с очередями из FreeBSD, также одна CAS-операция, но без необходимости отключения preemption на время push/pop.

6. в сравнении с DPDK, также одна CAS-операция, но без риска busyloop при вытеснении потока посередине push/pop, другими словами DPDK очереди obstruction-free, а в 1Hippeus гарантируется lockfree.

7. в отличии от очереди NatSys-Lab (http://www.linuxjournal.com/content/lock-free-multi-producer-multi-consumer-queue-ring-buffer) в режиме использования XADD и конкурентном overflow/underflow выполняется откат с "инвалидацией" отдельных позиций в очереди. Поэтому вероятность сваливания в obstruction-free существенно меньше. Более того, как уже отметил, текущая реализация "инвалидатора" гарантирует lockfree для двух писателей/читателей (внутри один интервал, а не список).

8. еще одно отличие от NatSys-Lab в использовании 32-битных указателей "по модулю", а не 64-битных с гарантированным крахом при переполнении. Такое переполнение конечно скоро не случится, зато реализация хорошо ложится на 32-битные архитектуры.

9. на основе PI-futex-ов есть механизм передачи квантов времени "заснувшим" продьюсерам или консьюмерам, грубо говоря автоматический yield(), который опционально отключается.
<software> Поиск 








Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2019 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach