@jtootf, Шикарная штука! 10x

@jtootf, процентов 94 банальщины, процента 5 спорных вещей и 1 процент действительно интересен. это довольно много, спасибо за ссылку )

@koshechka, можно озвучить спорные вещи?

@jtootf, подписываюсь

@dk, сейчас времени нет, попозжа напишу

@koshechka, eventhelix.com — вот например, пункты 15,16,21,22 спорны. вообще техническая часть относится либо к 1 проценту либо к 94

@koshechka, к 21 можно придраться, хотя consider — это и нестрогое указание,- но в чём провинились пункты 15, 16, 22?

@koshechka, Насчёт 15, 16, 21 — инкрементирую.
А вот 22 кажется мне вполне разумным.

@dk, ну хоть ты тогда их прокомментируй, что ли

@dk, жажда кнопки заебись — это шаг к ,хм, макбуку )

@koshechka, wait.. oh shi..

@koshechka, я бы сказал, что это принцип KISS

@jtootf, мне таки кажется что KISS в разумном копромисе между конфигурабельностью и кнопкой. что же по пункту — никто ведь не мешает задать дефолтные значения которые подходят для типичной конфигурации

@jtootf,
15: "Prefer general purpose computing platforms over specialized platforms"
Очень спорный пункт. Domain purpose платформы часто стоят на порядки дешевле general purpose, они более просты и имеют больше функциональности для реализации своей предметной области. Зачем переплачивать за навороченного монстрика, который умеет всего понемногу, если есть железка, котороя умеет делать только мелкий набор вещей, но делает его хорошо? Насчёт отсутсвия специалистов — полный берд. Если человек разобрался хоть с одной general purpose платформой, то разобраться с domain purpose для него вообще не составит труда.
16: Do not use proprietary protocols/operating systems
Если проприетарное решение лучше, почему бы его не использовать? Примеров тому масса: я лучше куплю vxworks, чем буду рыться в какашках uclinux.
21: Consider hardware upgrades to reduce software effort
Спорный пункт. Зачастую переход на новый хардварь требует серьёзной модификации софтвари.

@koshechka, система должна быть простой, насколько это возможно, но не проще; понятно, что баланс должен быть, но сделать много параметров куда проще, чем сделать мало — потому, с моей точки зрения, совет вполне здравый

@jtootf, суть не в том чтобы сделать много параметров или мало. суть в том чтобы удолетворить хотелки кастомера с минимальными затрахами. с этой точки зрения совет спорен )

@dk, 15 — вообще обычно domain-purpose железо стоит существенно дороже — во всяком случае весь мой опыт указывает на это, поэтому аргумент звучит чуть более, чем странно. насчёт специалистов — одно дело найти человека для работы с x86-чипом, другое дело — для работы с (например) DSP-процессором. понятно, что разобраться можно всегда и во всём, но с платформами общего назначения опыт получить куда проще, а следовательно и людей найти — тоже

@jtootf, Ну например mpc866 стоит ~ $50. (пруф: freescale.com
Я боюсь даже предположить, сколько стоит борда с интелом, дающая подобную функциональность.
Насчёт специалистов: если смотреть в internals инициализации контроллеров, фичей и прочего гумна x86-family, то внезапно они оказываются на порядки более сложными, чем те же армы, поверписюки и мипсы. Одни голимый APIC чего только стоит. Если человек разобрался в интерналах x86, то освоение любой другой архитектуры — это дело нескольких дней максимум. (насчёт любой я конечно загнул, какие-нибудь навороченные гадости типа cell'а или ниагары займёт поболее)

@jtootf, отчего же, типичный ARM SoC стоит копейки по сравнению с аналогичной x86 железякой,

@dk, 16 — vendor lock-in, отсутствие внешних стандартов. если ты работаешь с открытым стандартизованным протоколом, ты в любой момент можешь поменять реализацию любого из уровней OSI (в рамках доступных); если протокол приприетарный, то выбора у тебя нет. нет возможности сэмулировать проприетарное железо, потому что вендор не даст тебе спецификаций; нет возможности внести уровень абстракции в ПО, потому что вендор зафиксировал API в закрытом коде. да, иногда проприетарные решения работают лучше, но тогда их выбор — просто меньшее зло из имеющегося

@koshechka, Кстати, не забываем ещё про xilinix FPGAшки

@jtootf, про проприетарные протоколы соглашусь, но проприетарные реализации открытых стандартов будь это POSIX или TCP/IP использовать можно и нужно если они лучше открытых аналогов

@jtootf, Проприетарные решения, как правило — это готовые законченные продукты с достойной поддержкой пользователя и хорошей документацией. Если есть деньги, почему бы не сэкономить время? Потому что в противном случае придётся тратить немало времени на допиливание какой-то недопиленной поделки.
Да, есть достойные open-source продукты и есть достойные открытые протоколы, но их мало. Особенно под конкретные специфические цели.

@dk, Atom 230: $26, TMS320DM6446AZWT: $35.65. это сам чип. TI'шная плата с daVinci обойдётся в ~$1k

@koshechka, какой, например?

@jtootf, дык у тебя в конце концов будет своя кастомная борда

@dk, у FPGA очень узкая ниша реальной применимости, потому рассматривать их наравне с x86 и ARM-чипами смысла нет. это не альтернативные решения

@jtootf, пожалуй не соглашусь. что имеется в виду под реальной применимостью ?

@jtootf, ну например MV782xx, стоимость меньше 80 баксов

@jtootf, У тебя получается кастомное и довольно кастрированное решение. Где там FEC? Где UTOPIA? Где 4 HDLC/PPP? Я очень сомневаюсь, что твоё кастомное решение обойдёт по перфомансу mpc8xx

@dk, потому что времени на борьбу с их закрытостью тратится ещё больше, и никакая техподдержка тебе тут не поможет. например, в упомянутой выше задаче эмуляции проприетарной железки на виртуальной машине — ты не получишь такой возможности до тех пор, пока сам вендор не реализует эту функциональность. на спецификации под NDA можно надеятся, но гарантировать их никто не будет

@dk, это ты вообще к чему?

@jtootf, Подчёркиваю: проприетарные рещения нужно использовать тогда и только тогда, когда это выгодно. Если вендор не может предоставить нормально SDK с эмуляшкой и нормальной доки, то зачем такое покупать? Почему-то нормальные вендоры всё это предоставляют. Можно посмотреть на cell SDK или, возвращаясь к FPGA, на xilinix

@koshechka, та, которую можно запустить на CPU, GPU, DSP-процессорах

@jtootf, На сколько я понял ты привёл пример кастомной сборки борды с atom'ом, которая будет аналогична приведённой мной в примере mpc866, я правильно понял?

@dk, nVidia это нормальный вендор? :) BMW это нормальный вендор? Harman/Becker, Continental — это нормальные вендоры?

@jtootf, Честно говоря не знаю, ни с одим из них я не работал. Но фирмы именитые (:

@dk, нет. я сравнил цены на атом и arm-чип

@jtootf, разве есть какие-то проблемы грузить код в fpga откуда угодно? все что нужно — чтобы старт-агент мог быть мастером на шине, а само fpga — таргетом транзакции

@koshechka, и какую на выходе получим производительность? и ради чего?

@dk, я с ними работаю в данный момент, и strictly poprietary and confidential у меня каждый день встаёт поперёк горла. да, я субподрядчик, и от непосредственно поставщиков железа меня отделяет цепочка бизнес-иерархии, но легче мне от этого не становится

@jtootf, странный вопрос, зависит от того что мы хотим получить. когда я был маленький мы делали shdsl модем на альтере, свободно работало 8 линков shdsl и 8 e1

@koshechka, ну вот есть у нас чип общего назначения, на котором работает реализация пары протоколов и DSP поверх операционки. можем мы перетащить эту задачу на какой-нибудь Spartan3, не потеряв производительность к чертям? стоит ли нам это делать?

@jtootf, 1) да, в общем случае это возможно. 2) однозначно не стоит. то что работает пусть работает :)

@koshechka, допустим ещё не работает. что может побудить нас воспользоваться для этой задачи FPGA?

@jtootf, получите, как минимум, возможность использовать более слабый цпу и возможность не тащить по реализации для каждой поддерживаемой операционки

@koshechka, числа, мне нужны числа. есть сравнение производительности FPGA-решения вместо того же ARM или Atom на соответственных задачах? есть сравнение энергопотребления? что касается операционок, то up to my experience железо в подобных задачах меняется куда чаще операционки, во всяком случае такую миграцию оправдать куда как сложней

@jtootf, есть доска xilinx ml510 с полностью софтовым PPC440, на него некоторое время назад портировали lynxos-178. результаты performance теста всего на 10 процентов хуже чем в случае ibm440ep с такой же частотой цпу. конкретных цифр к сожалению дать не могу. NDA

@koshechka, а по энергопотреблению/нагреву отличается существенно?

@jtootf, в пике загрузки жрет меньше чем ibm440ep где-то раза в два. про нагрев ничего не могу сказать, в американской серверной холодильники на высоте :)

@koshechka, s/загрузки/нагрузки

@koshechka, всё, с зарплаты беру плату со спартаном — буду экспериментировать :)

@jtootf, хы, мне наверное пора в маркетоиды идти... :)