>драйверы, которые якобы собраны для x86, на практике даже на Atom работают либо сильно медленнее тех же драйверов, но на современных i3 / i5
а на galileo будет еще медленнее, чем на Atom, увы. Инструкции, которых нет на Atom/Quark — в-основном SIMD, которые в kernel mode драйверах обычно не используют.
>гигагерцовых многоканальных осцилографов
У quark на такое мощИ не хватит, конечно. Как и у бОльшей части ARMов.
> призрачный — наличие шин вроде PCI/PCIe
Да, вся PC перефирия на USB/PCIe работает из коробки, драйвера для Linux/x86 — наиболее стабильные/оттестированные.
> Удобство разработки — весьма относительное
Наша команда будет стараться, чтобы превратить это в важное преимущество.
По предыдущему пункту, разработка для embedded как на PC, используя все возможные PC development perks — python/node.js, labview/mathalb, библиотеки типа opencv, и тд в этом духе может быть преимуществом. В последние года софт экосистемы ARM серьезно продвинулась в этом направлении, но еще не совсем догнала PC.
У него есть 10 pin JTAG. Intel System Studio поддерживает его через переходник на Intel JTAG, а потом нужен еще и Intel JTAG (или Macgraigor). Достаточно дорого, к сожалению.
Без отладчика можно baremetal/efi/grub разрабатывать и сейчас.
Мы скорее всего летом выпустим baremetal примеры. Я был удивлен, что очень многие хотят использовать baremetal. Интересно, почему?
>intel позиционирует quark как замену arduino
В этом предложении 2 ошибки.
Во-первых, не quark (это SoC), а Galileo — это Ардуино совместимая плата.
Во-вторых, зачем заменять Arduino? Galileo просто предоставляет совместимость с Arduino скетчами, и, главное, с Arduino shields, плюс программирование под Linux, Vxworks, Labview, и Intel Cloud agent. Это не замена Arduino, который непревзойден для задач, типичных для микроконтроллера. А quark — не микроконтроллер, а low-end x86 SoC application processor.
Кстати да, меня удивляют некоторые компании, которые на технических выставках ставят на свои будки только временный персонал или маркетологов. Часто инженера не найти. Мы в этом отношении молодцы, как минимум один инженер всегда есть у каждой стойки.
>Prenatal DNA Sequencing
>Данная технология является прорывной, потому что никаким образом не угрожает плоду матери, а имеющиеся до этой, методики, создавали угрозу выкидыша
Почему технология 2013 года? C 2011 года услуга продается, а разрабатывалась в двухтысячных мы в прошлом году сделали такой тест, а наши знакомые 2 года назад, там все уже несколько лет на потоке… Куча компаний его делают, и с друг другом судятся по поводу патентов.
>если, конечно, отбросить mem latency и кеш
Так и в x86 mem latency и cache — причина 90% jitter. Я согласен, что оставшиеся 10% — тоже важно, и у ARM этих проблем нет, но считать циклы инструкций на АРМ конечно гораздо удобнее, но учитывая память и кэш — примерно так же бессмысленно, как и на x86.
Совершенно верно. Когда я делаю тест в своей лабе, я знаю точно, откуда могут прийти SMI и еще на всякий случай мониторю SMI counter. Надо бы кстати добавить в код бенчмарка, спасибо, что напомнили!
Холивар — тоже может быть хорошим делом, если при этом стороны узнают что-то новое. Я неплохо знаю, как устроены x86 платформы, но совсем не глубоко знаю ARM. Поэтому мне было бы интересно понять, как можно решать проблемы с плохой совместимостью SMT, power management, deep OOO pipilenes, shared cache(фич, которые хорошо помогают производительности) и предсказуемость времени выполнения кода, необходимого ОСРВ.
Да, на ARM я тоже видел такую связку, только с threadX.
Если реализации новых ARM будут догонять x86 по производительности, им придется идти на те же самые компромиссы, которые усложняют реализацию ОСРВ на x86.
Либо посылать IPI, либо через общую память. Кстати в поставке как раз есть тест bench/503.slots, в котором поднимаются 3 независимых baremetal thread'a и измеряется скорость обмена сообщениями через lockless queue на общей памяти.
а на galileo будет еще медленнее, чем на Atom, увы. Инструкции, которых нет на Atom/Quark — в-основном SIMD, которые в kernel mode драйверах обычно не используют.
>гигагерцовых многоканальных осцилографов
У quark на такое мощИ не хватит, конечно. Как и у бОльшей части ARMов.
Да, вся PC перефирия на USB/PCIe работает из коробки, драйвера для Linux/x86 — наиболее стабильные/оттестированные.
> Удобство разработки — весьма относительное
Наша команда будет стараться, чтобы превратить это в важное преимущество.
По предыдущему пункту, разработка для embedded как на PC, используя все возможные PC development perks — python/node.js, labview/mathalb, библиотеки типа opencv, и тд в этом духе может быть преимуществом. В последние года софт экосистемы ARM серьезно продвинулась в этом направлении, но еще не совсем догнала PC.
Без отладчика можно baremetal/efi/grub разрабатывать и сейчас.
Мы скорее всего летом выпустим baremetal примеры. Я был удивлен, что очень многие хотят использовать baremetal. Интересно, почему?
В этом предложении 2 ошибки.
Во-первых, не quark (это SoC), а Galileo — это Ардуино совместимая плата.
Во-вторых, зачем заменять Arduino? Galileo просто предоставляет совместимость с Arduino скетчами, и, главное, с Arduino shields, плюс программирование под Linux, Vxworks, Labview, и Intel Cloud agent. Это не замена Arduino, который непревзойден для задач, типичных для микроконтроллера. А quark — не микроконтроллер, а low-end x86 SoC application processor.
>Данная технология является прорывной, потому что никаким образом не угрожает плоду матери, а имеющиеся до этой, методики, создавали угрозу выкидыша
Почему технология 2013 года? C 2011 года услуга продается, а разрабатывалась в двухтысячных мы в прошлом году сделали такой тест, а наши знакомые 2 года назад, там все уже несколько лет на потоке… Куча компаний его делают, и с друг другом судятся по поводу патентов.
linuxgizmos.com/intel-atom-e3800-socs-head-for-embedded-systems/
На следующей неделе буду в отпуске, может быть отдельный пост напишу о некоторых особенностях baytrail-I
Так и в x86 mem latency и cache — причина 90% jitter. Я согласен, что оставшиеся 10% — тоже важно, и у ARM этих проблем нет, но считать циклы инструкций на АРМ конечно гораздо удобнее, но учитывая память и кэш — примерно так же бессмысленно, как и на x86.
Порта ввода-вывода на x86 — легаси.
Если реализации новых ARM будут догонять x86 по производительности, им придется идти на те же самые компромиссы, которые усложняют реализацию ОСРВ на x86.
Фичи от Microsoft комментировать не могу.