Было "развёрнутым" комментарием к статье "О бесполезных элементах" ( https://m.aftershock.news/?q=comment/13774136 ).
Видимо, в следствие "ухода далеко в подвал" коммент или остался незамеченным, или до него смогли добраться только те, кому показалось неинтересным.
А мне хотелось бы получить реакцию от определённого круга здешних комрадов...
Не только потому, что я в этой тематике "варюсь" время от времени (и - по проектам иногда, и - по специальности ВУЗа), но и - потому, что очень многие не видят (или - не знают), об общей теории систем, "фрактальности" мира и подобии систем разной природы и масштаба.
Итак:
Организационные системы обычно создаются для решения одной или нескольких ТИПОВЫХ задач.
В самом начале "бесполезных" элементов там нет и быть не может.
Как, например, в 20-е - 30-е годы в СССР.
Почему?
Потому, что топология таких систем - прямое отражение топологи взаимосвязей функционалов, необходимых для достижения иерархии целей.
То есть.
Сначала описываются цели. Вернее - иерархия целей/подцелей.
Потом находятся (или придумываются) функционалы, которые реализуют достижение этих целей.
Потом, если система создаётся заново, то, в зависимости от "объёма"/трудозатратности/ресурсозатратности оцениваемого функционала, для его выполнения или заново организуется исполнитель, или такой функционал нагружается на/"приписывается" уже имеющимся "типовому исполнительному элементу".
Поэтому, в заново спроектированной "организационной структуре", её топология (почти) эквивалентна топологиям целей и функционалов. Отличия могут быть тогда, когда исполняющие элементы могут совмещать "функциональные обязанности", "НЕ МЕШАЮЩИЕ" друг другу и их топологии - не изоморфны.
В процессе проектирования, в системе появляются ещё дополнительные элементы, НАПРЯМУЮ, КАК БЫ, НЕ СВЯЗАННЫЕ С ВЫПОЛНЕНИЕМ КОНКРЕТНЫХ ЗАДАЧ ПО ФУНКЦИОНАЛАМ - обычно это элементы, работающие на УПОРЯДОЧИВАНИЕ ОБМЕНА ИНФОРМАЦИОННЫХ/РЕСУРСНЫХ ПОТОКОВ, появляющихся в процессе работы "основных" функциональных элементов. Такой тип элементов присущ "более универсальным" системам, которые заточены на решение более широкого спектра, нагружаемых на систему, наборов задач. Эти элементы - наиболее рИсковая часть любой системы. Потому, что именно они "гасят расхождения" между топологиями систем целей и задач, И - топологиями исполнителей.
Теперь обратим внимание на то, что цели и задачи постоянно пересматриваются, с течением времени. МЕНЯЕТСЯ их смысл и - САМОЕ ГЛАВНОЕ - находятся новые наборы функционала для их достижения и выполнения. Сиречь - «модернизация».
Но!
"Организационная структура" (топология) системы исполнителей, чаще всего, остаётся неизменной.
Например, множество заводов и промобъединений, которые были построены и образованы в 20-30-х годах, дожили до перестройки и сохранились позже, ПРАКТИЧЕСКИ НЕ МЕНЯЯСЬ.
А - наборы задач и способы их решений - менялись, причём - порой достаточно радикально.
До определённого момента времени, у системы исполнителей остаётся "резерв" (чаще - производительности), чтобы работать в новых условиях и "по новым требованиям".
У советских предприятий и управленческих структур, построенных в 20-30-е годы, такой резерв был примерно - до середины-конца 60-х. Потом они стали "захлёбываться" по причине уже радикального расхождения "топологий" и "природы" задач с "топологиями" и "возможностями" исполнительных элементов. Значительный вклад в такое "захлёбывание" вносили те самые, выделенные и упомянутые "элементы за штатом" (помните?, это - которые обеспечивали "связность" системы по потокам информации и ресурсам)
На западе такие сложности и проблемы тоже возникали раньше и постоянно.
Сначала они пошли по "явному" пути. Под каждый вид и поколение продукции проектировались/строились/организовывались ОТДЕЛЬНЫЕ, НОВЫЕ производственные единицы и их конгломерации. С приходом новых техпроцессов, бывало, что даже не модернизировались старые, а — тупо «шли на слом и в утиль»!
Два примера.
Пока не было нормального освещения, после появления железо-бетонных конструкций и зданий, офисные здания в Нью-Йорке стали тянуться на максимальное расстояние вверх и имели ОГРОМНЫЕ окна - чтобы максимально растянуть по времени использование дневного солнечного света для работы клерков. Потом, с началом массового выпуска ламп дневного света офисные здания и их окна "измельчали" ("вернулись к разумной норме и размерам"). Кроме того, в "классических" нью-йоркских небоскрёбах располагалось ОГРОМНОЕ количество фирм и фирмочек. А, после внедрения ЛДС - фирмы уже могли строить небольшие офисные здания "под себя".
Второй пример - из танкостроения. Вначале, оптимальным было признано строительство отдельных заводов под ДАЖЕ определённую модификацию танка (а - не только под отдельную конструкцию). Последний такой пример - производство американцами абрамсов. В определённые моменты времени, одновременно работало два завода под производство разных модификаций этого танка, а один их них перестраивался практически полностью с принятием следующей модификации машины.
С появлением гибких, перенастраиваемых, производственных линий, надобность в строительстве новых и "модернизации" старых заводов отпала.
В обоих случаях, кстати заметьте, что большая часть "перенастройки" касалась.... именно тех, "внесистемных" элементов системы - которые обеспечивали связь между "штатными" исполняющими элементами системы. В случае офисных конгломераций это были системы доставки «канцтоваров» или папок/пакетов с документами специальными посыльными (или - пневмопочтой), а на заводах - экспериментированием со связями между складами и сборочными пунктами или конвейером.
Заметьте, что в компьютерах, в подавляющем большинстве случаев, вирусы организуют атаку именно на какой-либо из таких, "обеспечивающих связность системы", элемент (будь то электронное устройство или блок, или — программная часть).
"Атаки на офисы" (промышленный шпионаж) идут тоже по "связям".
Побеги из тюрем организуются, чаще всего, с использованием слабостей в защите "связующих" элементов.
Почему так?
Потому, что используется основное свойство "универсальных связующих элементов" - НЕЗНАНИЕ "СЕМАНТИЧЕСКОГО НАПОЛНЕНИЯ" ТОГО, ЧТО ОНИ "ПЕРЕДАЮТ" ПО "КАНАЛАМ". Именно это свойство, собственно, и обеспечивает универсальность их работы. Они не могут проверить то, что передают! Они - "НЕ знают смысла" передаваемого.
... в отличие от "штатных" исполнительных элементов.
(Кстати именно поэтому, логика УСПЕШНОГО и быстрого проведения СВО, «в классике», требовала вывода из строя таких «элементов связности» - авто- и железно- дорожной сети! Но, видимо, там работает «другая логика», обусловленная «другими целями» «исполняющих элементов системы»......... )
Дальше об "бесполезности" элементов...
В процессе "перенастройки" системы исполняющих элементов под новые задачи, может сложиться ситуация, когда система выйдет в полный "разбаланс" по расписаниям работы элементов, а связные элементы - либо "захлебнутся" в потоках, либо станут недозагруженными/незанятыми.
Помнится был какой-то советский фильм, там "осуждалась забюрократизированность" одной конторы, "распределяющей приказы, постановления и справки", где работала молодая девочка, приготавливающая чай для сотрудников. Там, за спиной героя Филиппова, висела "Схема распределения и доставки директив и приказов" - эдакий ацикличный однонаправленный граф с одним стартовым, двумя-тремя конечными и КУЧЕЙ промежуточных узлов, на которых документы копировались, архивировались, распределялись между "потомками" по связям в графе...
Скорее всего, мы имеем пример организации, когда промежуточные узлы не возникли "сами собой" или злому умыслу/хитрожопистости начальства этой конторы. Думается, что, в процессе реорганизации отрасли/объединения, внешние (относительно данной конторы) источники и потребители документов были упразднены/сокращены/перепрофилированы... А начальство просто преобразовало часть «освободившихся узлов» в "промежуточные" элементы "обработки информации".
Кстати, и на Западе, и в СССР, в 30-е-60-ые годы, была профессия "вычислитель-расчётчик". Вот тогда — да, целый штат расчётчиков с «железными феликсами» на столах, объединялись в "топологии", аналогичные структурам «расчётных нужд».
И - именно оттуда масса методов организаций вычислений, кстати, перекочевала в алгоритмы и программы для ЭВМ.
Такие "вычислительные группы и отделы" были не только у Королёва и Курчатова с Туполевым, но и - ранее, во время войны - например, у Жукова, Рокосовского и в ГенШтабе, для планирования операций.
Собственно, успешность и "незатратность"/оптимальность работы системы - прямая функция от "степени идентичности" её структуры структуре решаемой задачи.
В вычтехнике это можно обеспечить наиболее гибко, наглядно.
И именно поэтому, сегодняшнее направление "поиска самой лучшей УНИВЕРСАЛЬНОЙ архитектуры процессоров" - в корне ошибочно и тупиково. Нет, конечно же, гигагерцы конструкторы и дальше будут "отвоёвывать" на нанометрах техпроцессов производства. Но это быстродействие НИКОГДА не сравнится со строго специализированными решениями "под задачу". Отсюда - самый оптимальный вариант видится в создании перенастраиваемых архитектур ("ПЛИСоподобные"). В отличие от универсальных подходов, там производство вычислений и передача данных между "исполнителями" таких вычислений не будет иметь "лишних" промежуточных элементов (буферизация, переходы между внутренними шинами, преобразования между внутренним и внешним представлением данных и т.д.).
В области организационных систем народ - тоже ищет решения. Например создают вместо строго деревьев иерархий "матричные" или "сетевые" топологии, с "перестройкой топологии". Но, они подразумевают уход, в специализации "исполнительных" элементов, от строгого набора стандартных действий к постоянно изменяемому "функционалу", что большинству народа НЕ нравится, да и не имеет оно на то желания, способностей и талантов ("...к пуговицам - претензии есть? - нет! пришиты накрепко - не оторвёшь!").
Многие видели спасение в "компьютеризации управления", когда множество «рутинных операций» перекладывается на набор специализированного ПО, обеспечивающего перестройку и поддержку разных "виртуальных" топологий в процессе переключения между разными проектами и набором задач. Пока (даже после 70-ти лет развития ИТ в этом направлении), успехи - ОЧЕНЬ скромные. Опять же - по причине чисто "человеческого фактора".
Комментарии
"Сначала они пошли по "явному" пути. Под каждый вид и поколение продукции проектировались/строились/организовывались ОТДЕЛЬНЫЕ, НОВЫЕ производственные единицы и их конгломерации."
Это у них по плану или по конкуренции?
"Кстати, и на Западе, и в СССР, в 30-е-60-ые годы, была профессия "вычислитель-расчётчик"."
и была книжка "12 принципов производительности"
https://pqm-online.com/assets/files/lib/books/emerson.pdf
К чтению, на подобную тему, ещё неплохо Тейлора присовокуплять.
Генри Форд его усердно изучал.
И - на практике применял.
А Владимир Ильич - очень сильно не любил. "Дажекющятьнемог!". Тейлор картинку Владимиру Ильичу портил на счёт классовых раскладов и обусловленностью всего в мире общественно-политическом ими...
До окончания "тендера" и выставления конкурентами своих образцов на полигонах - "по конкуренции", после подписания контракта (в случае выигрыша) - "по плану".
Там ведь ребята - будь здоров "не промах" - в контрактах с Пентагоном ("Дядей Сэмом") сразу закладываются условия выполнения НИОКРов и их "внедрения". В том числе и - по модернизации. В смысле формы и дисциплины финансирования - вплоть до порядка проведения по комитетам обеих палат Парламента.
Хотя и сами "тендеры" - тот ещё "рынок"...
Интересно, но очень сумбурно. Что является конечной точкой? В чём состоит задача? Чего хотите?
Мира во всём мире.
И - коммунизма - там же.
Мир - частное состояние бытия человека. Коммунизм - одно из возможных состояний экономических отношений. Почему вы думаете что эти решения существуют и они устойчивы? Или просто хотите невзирая на реальность?
Если не знаешь куда идёшь, то не всё-ли равно куда?
Нужен "идеал", "сверхцель".
В процессе движения к ним, попутно, решается куча всяких других задач и достигаются полезные результаты и наработки. Причём, реашаются они в "более общем виде", чем если бы это происходило в рамках узконаправленных работ, без "сверхцели".
Если вы программист (тем более - СИ-плюсплюсник), то объяснение такое: всякая задача или алгоритм только тогда завершены, когда они написаны максимально обобщённо ("темплейтно") - то есть, работают исправно и корректно для любого набора элементов параметризации.
Да.
В самом вашем изложении, есть такой "идеал", "сверхцель" ? Имея "сверхцель" несложно выстраивать и структурность изложения что упрощает и восприятие и понимание конечной задачи.
Не-а, там же - размышлизмы.
Частично - для тех, кто понимает.
А тем, кто - "никаким боком", оно и - не нужно.
Пусть дальше бодаются на темы, "что лучше - коммунизм или капитализм".
Вы исходите из ОЧЕНЬ упрощенного представления о том, как строятся организационные структуры. Вас извиняет только последняя фраза Вашего поста:
На самом деле в любом организационном строительстве человеческий, субъективный фактор -- решающий. Вот Вы пишете: "Сначала описываются цели. Вернее - иерархия целей/подцелей". И да, это так. Точнее, это ДОЛЖНО БЫТЬ так. Но опыт показывает, что уже на этом уровне начинается бардак, в результате которого и появляются ненужные элементы (и не появляются нужные).
Проблема в том, что на любом уровне принятия решений (от высшего руководства до частного человека) есть цели декларируемые, общие, открытые -- и есть цели действительные, частные, не высказываемые. В результате процесс целеполагания в крупных структурах приводит к тому, что общий вектор движения определяется не декларируемой конечной целью, а векторным сложением декларируемых общих целей и недекларируемых личных целей по всей иерархии ЛПР. При этом необходимо принимать во внимание, что в дальнейшем эти векторы общих (в меньшей степени) и личных (в гораздо большей степени) целей постоянно изменяются, колеблются, что не может не приводить к колебаниям в принимаемых в соответствии с этими целями решениях.
Написал наукообразно. Чтобы было понятно, рассмотрим на примере.
Середина 90-х. Некий крупный банк. Структура иерархическая, многоуровневая. По историческим причинам второй уровень после центрального -- привязан к субъектам РФ. Поставлена задача создать единую централизованную банковскую систему (чтобы не возникали ситуации типа "где вам карту выдали, туда и обращайтесь").
На тот момент в КАЖДОМ областном отделении уже года с 90-го существовала более или менее убогая банковская система (работать-то надо), причем, как правило, у руководителей отделений банка была тесная связь с разработчиками (поручик, молчать! -- не обязательно чисто коррупционная, просто при создании и настройке системы воленс-ноленс приходилось очень тесно сотрудничать, что устанавливало определенное доверие между заказчиками и конкретными исполнителями. Кроме того, принятие единой централизованной системы создавало для руководителей отделений изрядные проблемы: во-первых, смена системы -- это переобучение персонала, перезаливка данных (что очень нетривиальная задача, особенно при технологиях, которые использовались тогда), а во-вторых, в единой централизованной системе верхнему уровню руководства видно то, что происходит на следующих уровнях -- а оно этим уровням надо?
В итоге ни одно из принимаемых решений в тот период тупо не могло быть выполнено. Допустим, наверху делают ставку на систему А. Руководители отделений берут под козырек и делают вид, что ее внедряют. Примерно в конце квартала в одном, а то и нескольких крупных отделениях в системе возникает (сам по себе, конечно, в результате того, что система А плохая, в отличие от системы Б, -- ну, вы понимаете) косяк, приносящий банку не катастрофические, но заметные убытки. Возмущенные руководители отделений на совещании требуют, чтобы внедрение вредной системы А было остановлено. Путем многосложной интриги проталкивается система Б. Далее возврат на начало цикла, и так до... момента радикальной смены руководства всего банка. Новые люди, пришедшие на отделения, устойчивых связей с разработчиками не имели. Зато имели мотивацию показать себя при наведении порядка.
Точно то же самое происходит и при формировании оргструктуры, только еще и похлеще. Новый элемент оргструктуры создается не тогда, когда он нужен организации в целом, а тогда, когда он нужен кому-то конкретному в этой организации. Ну, или если его навязали сверху или извне (например, через законодательство). Если в организации нет никого, кому этот элемент нужен для каких-то личных целей (например, чтобы пристроить на руководящую должность родственника или получить лишний голос своего человек в коллегиальном органе управления), то будут приняты все возможные меры, чтобы данный элемент начал рассматриваться как бесполезный.
Я с этим знаком.
Не один седой вОлос - тому свидетель.
Но я вёл речь об "общем подходе" - практически о своего рода "сферическом коне в вакууме".
С "неидеалом" я столкнулся ещё в ВУЗе, при демонстрации, нами написанной, системы оценивания исполнимости некоего ОГРОМНОГО набора работ в рамках такого же огромного количества организаций.
Сейчас, я вот даже и не знаю, взялся бы повторить тот объем проектного и программистского труда, что тогда был явлен.
Была собрана огромная БД по НИИ, КБ, министерствам, предприятиям, описывающая эти организации по, выделенным нами, параметрам и критериям. Формировалась, по сути дела, модель всей организационной структуры (иногда - с точностью до цехов, иногда - ДО СТАНОЧНОГО АГРЕГАТА, тепловоза или пропускной способности участка автодороги или нагрузки на ось участка дороги или моста).
Потом запускался процесс имитационного моделирования функционирования всей системы с набором задач, которые эта система должна была решать. В системе можно было вводить и всяко-разные "возмущающие воздействия".
На выходе получали как интегральные времена, затраты по ресурсам, занятость элементов и т.д...., так и расписания "самочувствия" конкретного элемента системы. В том числе и - их изменения во времени.
Это было в середине 90-х.
Интерфейс был - очень навороченный и красивый, для того времени. С наглядным представлением в виде гистограммок-"пирогов" у элементов, и - прочей отчётной шлабудени.
При первой же демонстрации я стал свидетелем, как у представителей Заказчика постепенно меняется выражение лиц, когда стало понятно, что система "тупо и наглядно" показывает, где моделируемая система "течёт". То есть, без вороха бумаг, отчётов, заседаний, командировок, ... можно - просто, "по оттенку цвета и величине столбца диаграммы", было увидеть "узкие места".
Все работы нам оплатили, выдали премии, присвоили звания, защитили дипломы...
...И - засекретили работу.
Я потом, "в частном порядке" и "по знакомству-дружбе" применял её в нескольких местах для "оценки систем" - в одной торгашеской фирме (торговля сантехникой и отопительным оборудованием), в фирме грузовых такси и - для себя - для моделирований нескольких войсковых операций времён ВМВ (ну - просто потому, что уже была масса источников по ТТХ техники и вооружений, характеристики погоды и местности, и известны результаты, чтобы сопоставить с результатами моделирования).
Естественно, везде именно "человеческий фактор" и вылезал! :)
Интересно, что, чаще всего, как некая "дельта" между желаемым/прогнозируемым поведением системы и тем, что - в реальности было или получалось.
В случае с торгашами, когда "повылезали" эти "дельты", даже пришлось очень стрёмные объяснения иметь (чуть ли не "стрелка" была ) и, месяца три-четыре, потом "ходил и оглядывался". :)
Еще один тезис в копилку — управление и развитие в системе возможно только тогда, когда в системе есть резерв (резервные мощности, резервные ресурсы) по отношению к текущему режиму работы. Для устойчивости системы резерв должен быть всегда,что приводит к "неэффективности" системы "в моменте".
Например, иногда тот факт, что со стороны ИТР вроде бы имеет возможность "ковырять в носу" якобы требует его немедленной оптимизации, что, мягко говоря, не слишком дальновидно.
Это - не всегда так.
Очень часто система может быть оптимизирована через перестройку её структуры/топологии.
Но конкретные решения должны приниматься в конкретном случае, конечно.
"Резервы", чаще всего, закладываются от неясности (НЕИЗВЕСТНОСТИ) всех параметров, факторов и ограничений.
Как пример из практики проектов в ИТ.
Раздолье и возможность "чесания ЧСВ" у проджект-менеджеров - в областях связанных с веб- и мобайл- разработкой. Там "разбросов" параметров меньше, чем в эмбеддинге (особенно там, где ещё и само "железо" надо проектировать). Поэтому был не раз свидетелем, когда, "сделавший несколько успешных проектов в веб-разработке", менеджер оказывался просто сосунком никчёмным, при попадании на проект по разработке встраиваемой системы.
Причём, если в проектах веб и мобайл неопределённости и разбросы - минимальны (там менеджментом уже успешно принято некое "шкалирование"), то оценки времён и трудозатрат в проектах разработки систем управления - полный трындец!
Мы, вот, над "долгостроем" Ф-22 и Ф-35 или в космических агентствах хихикаем, а я - вполне понимаю "визави". Им - не позавидуешь! Это вам - не очередной "интернет-магазин лабать"...
Не, резервы должны быть — это факт. Как пример, плотные графики, будь то движения, буть то производства. Если нет в графиках резервов — любое возмущение приводит к коллапсу. Это просто аксиома.
Эту тему хорошо развивает Голдрат в своей "теории ограничений". См. книгу Цель.
Нет. Не аксиома.
Аксиому я уже выше привёл.
Резерв - защита от неизвестности.
У меня было несколько проектов (встраиваемые системы), когда более качественный анализ условий работы системы, позволял применять более дешёвые средства реализации. Что, в конечном итоге, удешевляло систему (не такой мощный процессор или микроконтроллер, более "слабые", но дешёвые АЦП, не такие "навороченные" библиотеки и методы вычислений...). Когда это единичный/малосерийный экземпляр - разница не заметна. А когда изделие десятками-сотнями тысяч будет выпускаться, эффект - "ничегосебе"!
Например, в одном проекте, как оказалось, можно было не только не использовать ядро с плавающими, но и снизить разрядность с 32 до 16. ПРИ ПОЛНОМ СОХРАНЕНИИ ФУНКЦИОНАЛА И ПОВЫШЕНИИ НАДЁЖНОСТИ РАБОТЫ блока. Себестоимость изделия была снижена более чем на порядок, при сохранении цены для субподрядчика на том же уровне :). Заказчик настолько "растрогался", что я потом, на премию, выплаченную единоразово им, смог на полтора года в "творческий отпуск" уйти и заниматься только тем, что мне интересно было (по специальности) и что давно откладывал.
Поясню. Если рассматривать вокруг себя мир как детерминированный, и системы строить детерминированные - вопросов нет, такая точка зрения понятна и имеет место быть. Но! В реальном мире, стохастическом, это не так. Потому и системы должны строиться соответствующим образом. Вам очень повезло, если приодится иметь дело с детерминированными системами. Хотя откуда же понятие неизвестности/неопределенности? именно из стохастического мира, так что...
Не буду спорить.
Моим "коньком" является "реинжениринг" систем.
Мне нравится, когда, занятый функционалом на 90-95%, рабочий такт системы, которую разрабатывали и сопровождали уже не один год, после моего "вмешательства", "вдруг" "худеет" до 10-35%...
Осторожно, отчасти, повторюсь: там где начинают говорить о "стохастическом подходе", "решениях, основанных на статистических зависимостях" - просто не до конца проработана предметная область. По сути, сейчас. например, то, что называют "элементы ИИ" - именно такие подходы. Мы - просто имеем системы уравнений, манипулируя с показателями и коэффициентами при элементах в которых, "подгоняем" ("обучаем") систему под известные результаты при известных аргументах. Имея, при этом, робкую надежду, что у нас, на самом деле процессы описываются совокупностями гладких непрерывных функций и что то, что "между" "попаданиями по решениям" будет "работать" также верно (ну, "+/-"). :)
Резерв (ресурса) есть функция времени. Если времени достаточно, то и резерв минимален до нуля. Ну а время обеспечивается предсказательной силой что есть также ресурс. Так-что тут баланс ресурсов разного типа.
Лучше модельное время не привязывать к "физическому".
Событийность.
Вспомнил отрывок на тему из книги Хазина и Щеглова (как я понимаю, это, как раз, от С. И. Щеглова).
Как видим, элементы могут становиться весьма самостоятельными. И думаю, проблема СССР была, в том числе именно в превращении "инструментов" в "институты", которые начинали тянуть на себя ресурсы государства.
"ПЛИСоподобие" улыбнуло
Я подумывал: можно ли на плисине построить смартфон, чтоб уменьшить вероятность закладок.
НУЖНО.
разумеется, нельзя
на ПЛИС, в лучшем случае, можно построить часть цифрового ядра смартфона, причем крайне неэффективно. Более того, эта часть ядра будет работать по программе, которая является идеальной средой для т.н. "закладок".
Хотелось бы понять, на чем строятся Ваши оценки. Какова сложность процессора, который можно построить на современных ПЛИС? Как эта сложность соотносится со сложностью процессоров смартфона?
По моему, основная проблема будет в энергопотреблении.
Есть закладки в железе и закладки в софте. Я как владелец смартфона закладки в железе проверить не могу. А закладки в любом софте - могу. Сам или силами экспертов.
Ну прямо коллекция заблуждений :)
На современных ПЛИС невозможно построить современный процессор (способный быть ядром сматфона), но можно смоделировать его части.
"Разумный" предел для ПЛИС - младшие ARM Cortex.
Уже лет 10 как в ПЛИС включаются аппаратные ядра ARM (как правило, не более двух) и ядра (развитые ALU) DSP (бывает много, десятки).
Энергопотребление ... не является ограничивающим фактором.
Основные - цена, быстродействие и программная совместимость.
Это прямо указывает на неэффективность реализации функций управляющих или вычислительных ядер путем стандартной конфигурации универсальных ресурсов ПЛИС.
Море вентилей используется для межкоммуникаций внутри ПЛИС или для реализации +- нестандартных интерфейсов, "стандартные" же интерфейсы в ПЛИС-исполнении имеют тенденцию к реализации на базе встроенных аппаратных IP-блоков.
Вы, как владелец смартфона и даже с помощью экспертов, не можете проверить (и исключить) наличие закладок - ни (вымышленных кем-то) аппаратных, ни программных. Это отдельная тема и к ПЛИС отношения имеет мало.
Ну, имелась в виду возможность перестраивания архитектуры "на лету".
Не факт, что это будет похоже на то, что сейчас называют "FPGA"...
"Перестраивание на лету" (частичная реконфигурация) требует избыточности, причем, дикой.
Там, где специализированный вентиль, условно, это 4 транзистора, в вашем плисоподобии "универсальный" вентиль - это 100 транзисторов (из которых, в лучшем случае, работать на задачу будет четверть) и десяток шин, висящих мертвым грузом.
Идея реконфигурации железа (за исключением ну очень специфических случаев) - порочная.
И, если угодно, реконфигурация в классических вычислительных архитектурах изначально достигается т.н. "системой команд", т.е. она естественна для любого вычислителя, работающего по программе.
Короче, утопия
смятение чувств?
вы там поосторожней
Не..., совершенно спокоен.
Просто, смешно.
Серьёзно! :)
А у меня вот гуманитарии обратные чувства вызывают...
Серьезно
Универ (ФФ) и технический ВУЗ. Аспирантура, там же.
25 лет разработки систем управления для авиации и космоса.
Так шо, лубьязный друк, ваш номер - семнадцатый.
Не нужно кривляться.
Просто допустите, что на свете есть люди взрослее, опытнее и воспитаннее.
Про технический ВУЗ улыбнуло.
А про 25 лет разработки... ну есть у меня в команде молодежь с таким смешным бэкграундом, правда, поскромнее вас.
Чего и вам желаю.
Не юродствуйте и не клоунничайте.
Это вас не красит.
Вы понимаете, что можете внезапно столкнуться с жестокой реальностью?
И вам это может ОЧЕНЬ не понравиться...
Ваши выкладки про потребное количество транзисторов для перенастраиваемых архитектур - из разряда "Лондон утонет в конском навозе"...
Будете ещё беспочвенно и невежественно выделываться - пойдёте в бан.
С интересом прочитал. Не будучи специалистом, вот какие мысли вертятся: я спорил с руководителем, что он старается внедрить решения от гигантов ит индустрии, а какая адаптированная самописная программа решила бы проблемы в разы эффективнее. Он отвечает, что эти решения хороши когда есть энтузиаст, который с разной степенью эффективности старается что то внедрить. А вот он уйдет и система всё более бесхозно и бесполезно работает и превращается в хлам. Её некому развивать, нет подготовленных специалистов для работы с ней, при её поломке не найти мастера. А берёшь громоздкую и дорогую систему - всегда есть поддержка, есть мастера починки и разработки, она и сама всё далее развивается. Такие системы учитывают проблемы, которые еще в потенции и незаметны в организации. Готовое масштабное решение от крупного разработчика - это рабочий вариант при всех издержках, а полная адаптация под конкретный набор проблем в организации - это в большинстве случаев тупик.
Перспективный чат детектед! Сим повелеваю - внести запись в реестр самых обсуждаемых за последние 4 часа.