Ну как вам сказать… Переписание скриптов с grep'ами — это тоже обучение нейронной сети, которую мы привыкли называть мозгом. Оно, кстати, тоже занимает некоторое время.
Эта моя фраза говорила примерно о следующем: запускать параллельно несколько однопоточных обучений или последовательно запускать многопоточные обучения — это почти одно и тоже. А нам похоже всё равно придётся несколько сетей тренировать, ибо никто не гарантирует, что мы при обучении не упрёмся в локальный минимум. Так же дополнительные нейронные сети нужны для выбора констант — weightdecay и momentum. Но это конечно если я правильно понял теорию.
ПС. А так да, подход с многопоточным обучением одной нейронной сети более масштабируем, чем несколько паралельных однопоточных обучений.
ППС. ИМХО, первым кандидатом на распараллеливание является этап перемножения матриц.
ПППС. За QuickProp и PRProp отдельное спасибо, пойду про них почитаю…
Учитывая, что больших файлов у нас не водится, writing очень хорошо коррелирует с тормозами backend'а. Вообще, когда мы разбирались в проблеме мы строили графы на основе php-fpm-slow.log'а — там всё было как на ладони.
Слишком много всего нужно учитывать: Broadcast штормы, ARP спуфинг, STP root hijack, VLAN hopping. Это только то что с ходу вспомнилось, на практике я думаю на практике там много больше всего(соответственно ACL'и на свитчах будут гигантские). Так что лучше перестраховаться и давать клиентам L3.
Основной смысл multicast адреса на L2 в том, что даже умные свитчи понимающие IGMP/MLD не будут заглядывать в L3 заголовок для определения типа пакета — оно не нужно ибо всё отражено в MAC-адресе(хоть и не без false-positives). Да и в FDB, насколько я понимаю, хранятся не IP'шники, а MAC'и.
Так же заметьте, что multicast трафик не будет нагружать CPU железки которая его не должна принимать. Сравните вывод tcpdump и tcpdump -p.
Есть 2 вопроса:
1) Почему STP BPDU «который явно должен рассылаться броадкастом и всем» шлётся не на FF:FF:FF:FF:FF:FF?
2) Зачем конечному хосту не совместимому со стандартом 802.1D получать BPDU?
Почему? Последние версии GPFS нормально работают с гетерогенными средами и позволяют мигрировать горячие данные.
Впрочем, это тоже на важно, всё равно самое горячее будет в pagepool'е
Как бы не было дерзко это предложение, оно имеет смысл.
ОС — это не только ядро, но и набор прикладного ПО, которое зачастую имеет смысл писать на скриптовых языках типа shell/Python/Ruby нежели на Си.
Насколько я понимаю у всех крупных CMS/Framework'ов защита от csrf встроена.
Крупные конторы пошли ещё дальше и встроили защиту прямо в http-сервер.
Начинать писать собственное решение не ознакомившись с уже существующими реализациями, как минимум, не профессионально.
Как говорится: Those Who Forget History Are Doomed to Repeat It
ПС. А так да, подход с многопоточным обучением одной нейронной сети более масштабируем, чем несколько паралельных однопоточных обучений.
ППС. ИМХО, первым кандидатом на распараллеливание является этап перемножения матриц.
ПППС. За QuickProp и PRProp отдельное спасибо, пойду про них почитаю…
Так же заметьте, что multicast трафик не будет нагружать CPU железки которая его не должна принимать. Сравните вывод
tcpdumpиtcpdump -p.1) Почему STP BPDU «который явно должен рассылаться броадкастом и всем» шлётся не на FF:FF:FF:FF:FF:FF?
2) Зачем конечному хосту не совместимому со стандартом 802.1D получать BPDU?
Приведу тут ссылку на самый достоверный источник(с) Multicast address
Диски летят все одинаково*
Впрочем, это тоже на важно, всё равно самое горячее будет в pagepool'е
ОС — это не только ядро, но и набор прикладного ПО, которое зачастую имеет смысл писать на скриптовых языках типа shell/Python/Ruby нежели на Си.
Крупные конторы пошли ещё дальше и встроили защиту прямо в http-сервер.
Начинать писать собственное решение не ознакомившись с уже существующими реализациями, как минимум, не профессионально.
Как говорится: Those Who Forget History Are Doomed to Repeat It