Кстати IBM Power4 серийные образцы на 5 ГГц работают, вот только это несколько иное ядро и средняя вычислительная мощность иструкции архитектуры Power иная чем у x86.
Рискно набрать минусов, но для любого кто хоть как-то слушал курсы микропроцессорной архитектуры и электроники начало статьи полный бред.
Длительность выполнения части/инструкции не меряется во времени, а меряется в тактах процессора. Ничего в процесоре синхронизированного с тактами генератора не происходит(за исключением советских асинхронных архитектур, которые канули в лету).
Дальше уже можно не читать, потому что ваши предположения построены на полностью ложных предпосылках. Читайте лучше Хеннеси и Патерсона, Computer Architecture, Fifth Edition: A Quantitative Approach John L. Hennessy (Author), David A. Patterson (Author). На компьютерной инженерии рассказывают примерно на третьем курсе.
Есть разные стадии конвейера, выборка, декодирование, исполнение и т. д. каждая в разных архитектурах занимает определенное количество тактов. И если вы откроете руководство разработчика про архитектуре х86 от Интел или АМД вы также не увидите времени исполнения инструкций, а увидите количество тактов.
Если говорить точнее почему не увеличивается частота, лучше чем Интел я не напишу наверное:
И на хабре было несколько статтей от Интела о «тёмном кремнии» Жизнь в эпоху «тёмного» кремния. Часть 1 Жизнь в эпоху «тёмного» кремния. Часть 2 Жизнь в эпоху «тёмного» кремния. Часть 2
где упоминается закон Деннарда, а также любимый вопрос экзаменационных билетов закон Амдала.
А также нужно упомянуть о росте тока утечки при росте частоты и о том что размеры элементов настолько малые по сравнению с скоростью распространения сигнала кристалла и длиной шин что для нужно добавлять синхронизирующие элементы которые дополнительно усложняют схему(где то видел цыфры, что для интел уже более 10% кристала) и ограничивают рост частоты(разработчики на больших FPGA стыкаются достаточно часто на больших чатотах).
Всё конечно класно, но к сожалению в теории. Имел опыт «перебирания» проэкта клииента от PivotalLabs.
Покрытие тестами было но далеко не идеальное, достаточно много устаревших тэстов и достаточно много кода, который ничего не делал и непоятно почему остался. Отдельная песня, это инструкция по поднятию проэкта, очень много специфических для машин разработчиков вещей, в результате удалось поднять только во время визита онсайт под присмотром ихнего человека.
Pivotal Tracker ужасная система, сложно понять что происходит сейчас, а «интелектуальность» системы которая пытается всунуть в следующий спринт то что она считает реальным исходя из предыдущей скорости, а не то что нужно клиенту доставила много неприятных моментов.
В остатке, отдали проект ребята конечно в значительно лучшем состоянии чем это обычно случается от других аутсорсеров, но если они бы действительно следовали всем перечисляемым практикам, он бы мог быть лучше. Pivotal Tracker — это то что случается когда преобладает догматизм вместо «здравого смысла».
Красиво конечно, но не более чем украшательство.
На кой черт там столько дисков, гонять большое количество виртуалок, ядер мало, дисковый массив, просто неэффективное использование электроэнергии.
Могу порекомпндовать для немодифицируемыъ списков библлиотеку Immutable Collections blogs.msdn.com/b/bclteam/archive/2013/03/06/update-to-immutable-collections.aspx
А насчёт Count для IEnumerable я точно знаю что реализирована Generic специализация для List которая вызовёт именно IList метод Count вместо обобщённого, а чтобы не было проблем с LINQ to SQL смотреть всегда что генерируется на вход SQL-сервера, очень часто даже простая смена порядка накладывания критериев выборки.
У вас слишком мало тестовых данных чтобы делать серёзные выводы.
Нужно значительно больше данных, ваш объём вообще влезает в одну страницу и ещё очень много места останется, которая самой СУБД скорее всего прокешируется в памяти, кроме того план иссполнения будет самый примитивный.
Самой большой проблемой и очень частым запросом в реальных приложениях идёт JOIN и очень часто проседание в производительности имеено здесь. Потому тэст стоило делать с JOIN.
А теперь добави сюда влияние индексов, а также тот факт что для различного количества данных СУБД может и будет исспользовать разные планы иссполнения, то мы поймём что писать свой самописный кеш не стоит, только если вы не съели зубы на даном движке СУБД и имеете очень хороший опыт в реализации. Да кстати то что работало у вас сегодна, может сломаться завтра на новой версии СУБД.
Очередной «silver bullet».
Теперь у универмагов Kohl самый быстрый отклик, но всех пофигу, потому что есть Amazon, Target, WallMart etc, а о универмагах Kohl я услышал в первый раз.
По архитектуре, хорошо разобрал Throwable.
От себя добавлю, такие картинки хорошо показывать на презентации менеджменту, потому как они люди внушаемые, им можно впарить всё что угодно, а здесь люди техничные и ясно что эта картинка не показывает ничего. Потому как у вас messageing server получает сообщения из космоса вестимо, потом гонит на бизнес слой, а слой презентации валит напрямую, нафига нам messenging слой?
Мне кажется что несколько плат, будет неэфективно изза енергобюджета и затрат на сочленение и передачу данных.
В обработке изображений я бы сказал две наиболее затратные задачи, первичная обработка картинки, лучше всего далать на DSP и распознавание образов, так как вы хотите нейронные сети, то возможно вам стоит попробовать делать это на FPGA.
Теперь из решений которые позволят это сделать:
1. www.finboard.org/ двоядерный DSP, заточен под обработку изображений, встроен готовый сенсор, большая библиотека готовых решений, из недостатков, «особенности» програмирования, небольшое комьюнити.
2. www.em.avnet.com/en-us/design/drc/Pages/Xilinx-Zynq-7000-SoC-Video-and-Imaging-Kit.aspx — ну что я могу сказать дорогой монстр
3. www.arroweurope.com/markets-solutions/solutions/vita-reference-kits.html — все ещё дорого
4. microZed — zedboard.org/ — нужно покупать io-board или делать самому, Xilinx-Zynq-7000
5. shop.adapteva.com/collections/parallella/products/parallella-16 — Xilinx-Zynq-7000, плюс 16-ядерное приданное, но как оно в реальности нужно пробовать.
Платы печатные, разумеется заказывать в Китае, но лучше всего через посредников, потому что посредники будут отвечать за качество. — и засекаем время за сколько любой мало мальськи успешный проект получит noname клонов. Если будете делать сами, то скопируют так же, но больше времени уйдёт.
mSATA — только разве на Intel платформе.
С native-SATA, по моему только Intel, AMD, FreeScale iMX6(Wandboard, UDOO), остальные через USB.
«полной поддержкой OpenSource» — нет ни в одном девайсе и пока вряд ли предвидится. Для некоторых платформ среверсили часть GPU чипа и понемногу пилят поддержку, лет пять наверное ещё нужно для быстрого 3D. www.fsf.org/resources/hw/single-board-computers
www.wandboard.org/ — 2 Gb памяти. О тормозном чипе, вы на нём что делать собираетесь? 1080p он декодирует влёт, причём драйвера постоянно улучшаются. Да это не Exynos, но без качественных драйверов на самсунговских чипах вы всё одно качественного результата не получите.
Для imx6 есть тэстовые сборки XBMC.
Лично я собираюсь заказать UDOO, хотя мне он нужен не для домашнего кинотеатра.
Насчет единственной готовой системы я бы поспорил.
Есть wandboard, и сонм других. И решения на базе TI, Freescale имеют лучшую поддержку производителя и сообщества. присутствует большее разнообразие готовых дистрибутивов и главное периферии.
А если нужен исключительно миникопъютер, я не понимаю зачем вообще такой огромный девайс, китайцы клепают «флешки» со скоростью света.
Как расширяемое устройство решения на базу Samsung, RockChip, MT плохи по причине малого количества доступных GPIO и периферии, На MT поддержка CAN задекларирована, но не работает в принципе, например.
Спасибо посмотрел. К сожалению главной задачи домашней автоматизации вы не решаете. Вы взялись то что ближе вам UI.
С тех задач что я зараз рассматриваю:
— Device discovery
— Multiprotocol processing
— Extending network
— Network topology
Не решается никакая. Возможно для вашей топологии это и подходит, но мне нет.
Вот сравните ваше решение например с github.com/stianeikeland/homeautomation
Уже четко видно что event-based архитектура, я могу предвидеть точки расширения.
В самом примитивном виде home automation контролер должен существовать вообще без UI.
По прерыванию от внешнего события будится демон, который принимает или отправляет сообщение, кладет его в service bus и все его работа на этом окончена. Другие модули в том числе и UI просто подписчики на события шины. ZeroMQ/Crosroads + возможно redis как слой сохранения данных как будто для таких систем созданы. В результате части системы не завязаны один на другой и могут быть взаимозаменяемыми и опциональными. По сути из обязательных, слушающий демон, service bus, и накопитель данных, дальше добавляем обработчик который будет тригерится по определенным событиям.
Для работы с топологией уже есть некоторые задумки, но пока еще не оформились в окончательное решение. Пока едет BBB гуглю альтернативы, чтобы не изобретать велосипед.
Speedtest давно не показатель скорости. Проигрывание youtube hd без запинок, скачка чего-то объемного с сайта Microsoft, Adobe, потому что у меня такое впечатление что некоторые провайдеры специально затачивают линк под speedtest, а youtube шейпят.
Ни слова о архитектуре. Контролер домашнеей автоматизации, єто не ООП изучить, а связать воедино устройстав в доме, получать, обрабатывать, анализироавть и реагировать на события в системе. UI же возникает как следствие.
И что здесь для BigData? Давайте прилепим к железке модный buzword авось кто-то поведется. Если кто-то задумает на этой железке крутить какую-то аналитику, быстро упрется в потолок низкого IO или низкой производительности. В большинстве Bigdata задач никто в здравом уме боле 10ТБ(а чаще всего менее 1Тб) на одном узле обрабатывать не будет. И производительность невысокая и надежность малая. Тот же Hadoop разбиваем на кусочки раздает маленьким узлам быстро обрабатываем потом результаты объединяем.
Увидел заголовок, обрадовался, неужели русские свой апаратно-программный комплекс заделали с Hadoop-ом готовым чтоб не собирать по кусочкам и железом соответственным, а оказалась посредственная железка из разряда «чуть лучше чем соберу сам» и с модным словом на этикетке.
Как все знакомо. Только мы не только предпросмотр генерировали, но и поддерживаемые форматы, вроде офисных документов в XPS и PDF конвертировали и потом показывали в встроенном просмотрщике. Именно конвертация и генерация привью самая «тяжёлая» операция. Кстати позже после обновления библиотеки конвертации мы могли повторно попробовать сгенерировать превью и документ сконвертировать для документов которые не были сконвертированы на предыдущей версии. К сожалению не взлетело, остался только памятник былой роскоши libreeze.com/
Предыдущая статья была хороша и все примеры увидел в реально жизни. Ваш же пример на мой взгляд натянут. За 5 лет работы лидом и много лет до до этого старшим разработчиком подобное если и замечал то редко. Да есть стремление к перфекционизму, но такого жесткого неадеквата не встречал. А причина вашей ситуации совсем в другом. Ваша «проблема» не стала проблемой человека к которому вы обращаетесь. Чтобы человек начал что-то делать это должно стать его проблемой и в этом проявляется умение руководителя. И против вас тут будет как раз играть нелояльность по умолчанию характерная для «наших». Ну прибыль какая-то, ну премия, а у меня тут он какие завитушки и изящное решение в прошломесячной проблеме никто не заценил и тут еще этот хочет чтобы я влезаал в задачу не по своему профилю, я то конечно могу, но ведь если им понравится могут потом постоянно таким нагружать. А вы как он такой сякой не смеет рвать части тела ради благой цели и почему-то еще размышляет вместо того чтобы начать вджобывать.
Это называется разговор слепого с глухим. Вы не слышите один одного и то что вы все еще программируете не делает вас ближе.
Причин у этого может быть много, но я не вижу с описанной ситуации что вы поняли что в первую очередь были неправы вы, вы недостаточно осмыслили ситуацию и пошли самым простым путем. Я напишу руководство что все должны шагать строевым шагом и каждую среду петь оды Луне и все разрешится. Во только если ситуация не меняется, возможно в постановке вопроса что-то не так и причина глубже?
Если у вас есть выбор и вы несовместимы и не пытаетесь совместится с мировоззрением «наших» программистов, есть выход конечно проще не нанимать таких и не браться такими управлять. Если выбора нет, нужно искать способ стать «своим», завоевать уважение и понять мотивацию сотрудника. Путь этот не простой, но ведь руководителю за вредность «кефир» полагается?
Длительность выполнения части/инструкции не меряется во времени, а меряется в тактах процессора. Ничего в процесоре синхронизированного с тактами генератора не происходит(за исключением советских асинхронных архитектур, которые канули в лету).
Дальше уже можно не читать, потому что ваши предположения построены на полностью ложных предпосылках. Читайте лучше Хеннеси и Патерсона, Computer Architecture, Fifth Edition: A Quantitative Approach John L. Hennessy (Author), David A. Patterson (Author). На компьютерной инженерии рассказывают примерно на третьем курсе.
Есть разные стадии конвейера, выборка, декодирование, исполнение и т. д. каждая в разных архитектурах занимает определенное количество тактов. И если вы откроете руководство разработчика про архитектуре х86 от Интел или АМД вы также не увидите времени исполнения инструкций, а увидите количество тактов.
Если говорить точнее почему не увеличивается частота, лучше чем Интел я не напишу наверное:
И на хабре было несколько статтей от Интела о «тёмном кремнии»
Жизнь в эпоху «тёмного» кремния. Часть 1
Жизнь в эпоху «тёмного» кремния. Часть 2
Жизнь в эпоху «тёмного» кремния. Часть 2
где упоминается закон Деннарда, а также любимый вопрос экзаменационных билетов закон Амдала.
А также нужно упомянуть о росте тока утечки при росте частоты и о том что размеры элементов настолько малые по сравнению с скоростью распространения сигнала кристалла и длиной шин что для нужно добавлять синхронизирующие элементы которые дополнительно усложняют схему(где то видел цыфры, что для интел уже более 10% кристала) и ограничивают рост частоты(разработчики на больших FPGA стыкаются достаточно часто на больших чатотах).
Покрытие тестами было но далеко не идеальное, достаточно много устаревших тэстов и достаточно много кода, который ничего не делал и непоятно почему остался. Отдельная песня, это инструкция по поднятию проэкта, очень много специфических для машин разработчиков вещей, в результате удалось поднять только во время визита онсайт под присмотром ихнего человека.
Pivotal Tracker ужасная система, сложно понять что происходит сейчас, а «интелектуальность» системы которая пытается всунуть в следующий спринт то что она считает реальным исходя из предыдущей скорости, а не то что нужно клиенту доставила много неприятных моментов.
В остатке, отдали проект ребята конечно в значительно лучшем состоянии чем это обычно случается от других аутсорсеров, но если они бы действительно следовали всем перечисляемым практикам, он бы мог быть лучше. Pivotal Tracker — это то что случается когда преобладает догматизм вместо «здравого смысла».
На кой черт там столько дисков, гонять большое количество виртуалок, ядер мало, дисковый массив, просто неэффективное использование электроэнергии.
А насчёт Count для IEnumerable я точно знаю что реализирована Generic специализация для List которая вызовёт именно IList метод Count вместо обобщённого, а чтобы не было проблем с LINQ to SQL смотреть всегда что генерируется на вход SQL-сервера, очень часто даже простая смена порядка накладывания критериев выборки.
Нужно значительно больше данных, ваш объём вообще влезает в одну страницу и ещё очень много места останется, которая самой СУБД скорее всего прокешируется в памяти, кроме того план иссполнения будет самый примитивный.
Самой большой проблемой и очень частым запросом в реальных приложениях идёт JOIN и очень часто проседание в производительности имеено здесь. Потому тэст стоило делать с JOIN.
А теперь добави сюда влияние индексов, а также тот факт что для различного количества данных СУБД может и будет исспользовать разные планы иссполнения, то мы поймём что писать свой самописный кеш не стоит, только если вы не съели зубы на даном движке СУБД и имеете очень хороший опыт в реализации. Да кстати то что работало у вас сегодна, может сломаться завтра на новой версии СУБД.
Теперь у универмагов Kohl самый быстрый отклик, но всех пофигу, потому что есть Amazon, Target, WallMart etc, а о универмагах Kohl я услышал в первый раз.
По архитектуре, хорошо разобрал Throwable.
От себя добавлю, такие картинки хорошо показывать на презентации менеджменту, потому как они люди внушаемые, им можно впарить всё что угодно, а здесь люди техничные и ясно что эта картинка не показывает ничего. Потому как у вас messageing server получает сообщения из космоса вестимо, потом гонит на бизнес слой, а слой презентации валит напрямую, нафига нам messenging слой?
В обработке изображений я бы сказал две наиболее затратные задачи, первичная обработка картинки, лучше всего далать на DSP и распознавание образов, так как вы хотите нейронные сети, то возможно вам стоит попробовать делать это на FPGA.
Теперь из решений которые позволят это сделать:
1. www.finboard.org/ двоядерный DSP, заточен под обработку изображений, встроен готовый сенсор, большая библиотека готовых решений, из недостатков, «особенности» програмирования, небольшое комьюнити.
2. www.em.avnet.com/en-us/design/drc/Pages/Xilinx-Zynq-7000-SoC-Video-and-Imaging-Kit.aspx — ну что я могу сказать дорогой монстр
3. www.arroweurope.com/markets-solutions/solutions/vita-reference-kits.html — все ещё дорого
4. microZed — zedboard.org/ — нужно покупать io-board или делать самому, Xilinx-Zynq-7000
5. shop.adapteva.com/collections/parallella/products/parallella-16 — Xilinx-Zynq-7000, плюс 16-ядерное приданное, но как оно в реальности нужно пробовать.
С native-SATA, по моему только Intel, AMD, FreeScale iMX6(Wandboard, UDOO), остальные через USB.
«полной поддержкой OpenSource» — нет ни в одном девайсе и пока вряд ли предвидится. Для некоторых платформ среверсили часть GPU чипа и понемногу пилят поддержку, лет пять наверное ещё нужно для быстрого 3D.
www.fsf.org/resources/hw/single-board-computers
Для imx6 есть тэстовые сборки XBMC.
Лично я собираюсь заказать UDOO, хотя мне он нужен не для домашнего кинотеатра.
Есть wandboard, и сонм других. И решения на базе TI, Freescale имеют лучшую поддержку производителя и сообщества. присутствует большее разнообразие готовых дистрибутивов и главное периферии.
А если нужен исключительно миникопъютер, я не понимаю зачем вообще такой огромный девайс, китайцы клепают «флешки» со скоростью света.
Как расширяемое устройство решения на базу Samsung, RockChip, MT плохи по причине малого количества доступных GPIO и периферии, На MT поддержка CAN задекларирована, но не работает в принципе, например.
С тех задач что я зараз рассматриваю:
— Device discovery
— Multiprotocol processing
— Extending network
— Network topology
Не решается никакая. Возможно для вашей топологии это и подходит, но мне нет.
Вот сравните ваше решение например с github.com/stianeikeland/homeautomation
Уже четко видно что event-based архитектура, я могу предвидеть точки расширения.
В самом примитивном виде home automation контролер должен существовать вообще без UI.
По прерыванию от внешнего события будится демон, который принимает или отправляет сообщение, кладет его в service bus и все его работа на этом окончена. Другие модули в том числе и UI просто подписчики на события шины. ZeroMQ/Crosroads + возможно redis как слой сохранения данных как будто для таких систем созданы. В результате части системы не завязаны один на другой и могут быть взаимозаменяемыми и опциональными. По сути из обязательных, слушающий демон, service bus, и накопитель данных, дальше добавляем обработчик который будет тригерится по определенным событиям.
Для работы с топологией уже есть некоторые задумки, но пока еще не оформились в окончательное решение. Пока едет BBB гуглю альтернативы, чтобы не изобретать велосипед.
Увидел заголовок, обрадовался, неужели русские свой апаратно-программный комплекс заделали с Hadoop-ом готовым чтоб не собирать по кусочкам и железом соответственным, а оказалась посредственная железка из разряда «чуть лучше чем соберу сам» и с модным словом на этикетке.
Это называется разговор слепого с глухим. Вы не слышите один одного и то что вы все еще программируете не делает вас ближе.
Причин у этого может быть много, но я не вижу с описанной ситуации что вы поняли что в первую очередь были неправы вы, вы недостаточно осмыслили ситуацию и пошли самым простым путем. Я напишу руководство что все должны шагать строевым шагом и каждую среду петь оды Луне и все разрешится. Во только если ситуация не меняется, возможно в постановке вопроса что-то не так и причина глубже?
Если у вас есть выбор и вы несовместимы и не пытаетесь совместится с мировоззрением «наших» программистов, есть выход конечно проще не нанимать таких и не браться такими управлять. Если выбора нет, нужно искать способ стать «своим», завоевать уважение и понять мотивацию сотрудника. Путь этот не простой, но ведь руководителю за вредность «кефир» полагается?