[identity profile] mikhai1-t.livejournal.com posting in [community profile] engineering_ru
Оригинал взят у [livejournal.com profile] mirvn в Вершина нашего развития [Машины и мы 01]

Это первая статья в, как я надеюсь, целой серии заметок о несправедливо игнорируемом аспекте нашей современной цивилизации.

Развитие цивилизации это коллективный путь к расширению наших знаний, всё остальное вторично: энергия, промышленность, космос - всё это плоды нашего стремления к познанию. Нужно понять цепочку причинно следственных связей, больше доступной информации -> больше знаний -> больше эффективных устройств -> больше энергии мы можем получать. Стоит вспомнить, что первые паровые двигатели - самые сложные механизмы ХVIII века - работали как насосы в угольных шахтах.

Поэтому сначала новые знания и новые механизмы, а уж потом новая энергия в необходимом количестве. Так что давайте отбросим разные предрассудки и скажем прямо: пик развития нашей сегодняшней цивилизации это iPhone. Вот пусть он у нас и отвечает за новые источники энергии.

Сири, где ближайшая бензоколонка?

Как я уже писал раньше, предшественником первой индустриальной революции был печатный станок Гуттенберга. Это изобретение позволило поставить процесс накопления и распространения знаний на экспоненциальный путь развития. Третья же индустриальная революция, перед порогом которой мы все сейчас топчемся, обусловлена изобретением и развитием информационных технологий. Компьютер - это одновременно и источник накопления и распространения знаний и один из самых сложных механизмов, которые мы сейчас способны делать. По аналогии с историческими событиями, это наш печатный станок и наша паровая машина.

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

На секунду отойдём от гадских айфонов и разберёмся с одной из самых брутальных мужских профессий, а именно геологической разведкой.


z4TuPrI.png

Геологи в поисках нефти. С романтикой гитар и палаток что-то пошло не так.


Добыча нефти, так же как и победа в военном сражении, невозможна без разведки. Ещё до начала бурения скважины вы должны хотя бы примерно представлять что вас ожидает под землёй, должна быть какая-то карта. Без карты добыча нефти превращается в попытку угадать вкус арбуза по узору кожуры. Основной метод разведки это сейсмическое исследование недр. Как это происходит?


Берут мощный источник вибрации, чтобы сгенерированные им волны имели достаточно энергии для проникания на необходимую глубину. Это либо специальный вибратор на шасси грузовика, либо углубление/скважина с заложенной туда взрывчатой. Упругие волны распространяются в глубину земных пород и частично преломляются и отражаются от разных слоёв обратно к поверхности, где их принимают сейсмоприёмники. Данные записывают специальным самописцем и вместе с данными об упругих свойствах горных пород это позволяет построить карту геологического среза глубиной до десяти километров. Теперь можно понять где находится нефтяная ловушка.


Используя метод вы видите двухмерное сечение поверхности, вместо объёмной картины. На виде “сверху” это выглядит как линия, а плоскость сечения видна при виде сбоку. Типа такого:


Результат 2D-сейсмической разведки. Нефтегазовые ловушки отмечены зелёным.


Понять реальность на основе этого снимка это как попытка опознать что нарисовано на правой картинке, открывая слева только отдельные линии:



Это возможно, если вы примерно знаете что ищите - к примеру, что это картинка некого человека или же вы определили хотя бы примерно где находиться нефть и вам нужно только уточнить ваши данные. Но с исчерпанием близких к поверхности месторождений нефти с простыми геологическими условиями метод становиться все менее эффективным и нужно покрывать всё бОльшую площадь со всё большей детализацией. А затраты на такое исследование растут пропорционально количеству наблюдений, которые вы записываете, а количество наблюдений растёт в квадрате с ростом площади исследования.


После некой границы ручная обработка данных становиться слишком дорогой и это ограничивает возможности добычи нефти, также как затопляемость английских угольных шахт и мощность ручной/лошадиной откачки ограничивала добычу угля. В обоих случаях понадобилась помощь специальных машин. Для английских шахт нужен был паровой насос, автоматизирующий откачку воды, а для добычи нефти - компьютер, записывающий и просчитывающий за вас всё увеличивающиеся объёмы данных сейсморазведки.


Разведка без iT - деньги на ветер


История сейсмики вертится вокруг компании GSI, которая её первой успешно применила в 1924 году, и информационных технологий. К 1950-м вместо бумажных носителей стали использовать магнитную ленту и аналоговую электронику на базе транзисторов. Пионером в этой инновации было подразделение GSI с неизвестным в то время названием “Texas Instruments” (легендарный изобретатель интегральных схем), а лицензию на производство транзисторов Texas Instruments купила именно для обслуживания потребностей сейсмической разведки. В 1960-х годах был переход от аналоговых систем к первым коммерческим цифровым компьютерам, что позволило увеличить скорость обработки данных и детализацию. Но всё ещё оставалось главное ограничение метода: двухмерность результата.


Первый эксперимент по производству трёхмерных сейсмических карт был проведён в 1972 году силами вышеупомянутого GSI и шести крупных нефтяных компаний. Сбор данных (500000 отдельных записей) занял месяц, компьютерная обработка целых два года. Для нефтяной индустрии проект по сложности был сравним с запускам первого спутника для космонавтики и результат оказался выше всяких похвал: на считавшемся исчерпанном нефтяном плее в штате нью-мексико удалось найти несколько новых месторождений.


Широкое распространение метод получил только в начале 1980-х годов прошлого века и только с развитием нового поколения суперкомпьютеров. Чтобы понять причины, достаточно посмотреть на стоимость одного гигафлопса в фиксированных долларах - ведь только в 1980-е стоимость обработки таких объёмов данных за нормальные сроки стала доступна отдельным крупным компаниям.

Selection_203.png


Расшифровка данных 3D-сейсмографии требовала колоссальных вычислительных ресурсов и компании 3D-сейсморазведки занимались обработкой полученных данных на мощных суперкомпьютерах того времени. Вот, например, прессрелиз 1996 года о заключении контракта между нефтяной компанией и университетским вычислительными центром Minnesota Supercomputer Center Inc (MSCI), где обработка данных велась на суперкомпьютерах CM-5 от Thinking Machines и T3D компании Cray. Вычислительная мощность составляла 52,6 и 76 гигафлопс, то есть практически без отставания от мирового лидера (150 ГФлопс), а CM-5 даже успел этим лидером побывать. Просто для интереса, параллельно написанию этого текста, я запустил бенчмарк на своём домашнем 4-ядерном core-i5 и получил значение в 89.25 гигафлопс.


Нефтегазовый айфон


Логика причинно-следственных связей тут проста как знаменитое “утром деньги, вечером стулья”. Сначала суперкомпьютеры, потом результативная разведка, потом нефть. В наши дни мы уже не так ограничены вычислительными возможностями и можем обрабатывать на порядки больше данных, чем мы могли даже в конце 1990-х. Из этого следует, что площадь сейсмических исследований уже по сути не ограничена этим аспектом. Но реалисты уже спешат напомнить, что мы живём в физическом мире где нельзя просто взять и опутать 10000 квадратных километров проводами и микрофонами. Что фура с проводами на картинке ниже в этом случае должна быть заменена карьерным грузовиком, а может и целым железнодорожным составом. А количество укладчиков будет сопоставимо с армией КНДР. Да, вы правы, правы.


13iLv4P.png


Ax, если бы мы могли избавиться от проводов, если бы у нас было устройство с сенсорами, микрофоном, GPS, радиопередатчиком, процессором, позволяющим управлять всем этим добром в реальном времени и, конечно, достаточно мощной батарейкой для бесперебойной работы. Кто сказал айфон?


К сожалению, идея уже реализована американской компанией в 2012 году:

Метросексуалы с айфонами в модном электрокаре (слева) против брутальных мужиков с прицепом проводов (справа)


Не отстаёт и православная Газпромнефть, которая испробовала эту технологию сначала в горном и опасном Курдистане, а теперь вовсю использует в замороженных лесах западной Сибири:


GJB_0624a1.jpg


Какой вывод? Главное не то что мы имеем от природы и где живём, главное это сумма наших знаний. На примере нефти, не надо пенять на природу, что она дала нам мало нефти - надо просто уметь её искать и добывать. До тех пор, пока мы продолжаем как вид увеличивать сумму знаний, наши возможности будут расти, ведь вселенная переполнена энергией и нужно просто знать как её взять. Сейчас самым главным инструментом познания для нас является компьютер, без которого современное существование просто невозможно. Хотите узнать потенциал цивилизации? Узнайте сколько у неё суперкомпьютеров.


Совместно с [livejournal.com profile] plaksiva9tr9pka

Date: 2015-01-13 01:59 pm (UTC)
From: [identity profile] ab-dachshund.livejournal.com
С твоих слов - нет, успокойся уже.

Забей на свои никчемные преподавательские таланты и переходи либо сразу к делу либо сразу нафиг.

Утомил, моралист.

Date: 2015-01-13 02:01 pm (UTC)
From: [identity profile] serpentthegreen.livejournal.com
Так я по делу.

Началось-то всё с того, что вы смешиваете управление памятью и программные интерфейсы.

Впрочем и .NET у вас "эмулируемый". C JVM перепутали, мелочь какая.

Date: 2015-01-13 02:21 pm (UTC)
From: [identity profile] ab-dachshund.livejournal.com
Ок. Отвечаю по сути - это вам показалось, что я смешиваю. Точно так же как вам (как я теперь понимаю) кажется, что какие-то видимые вам отличия двух букв от трех должны однозначно доказать мне, что я де что-то там смешиваю. Вы катастрофически переоцениваете силу своих аргументов, не говоря уж о своей внимательности к чужим.

А показалось вам потому, что вы склонны не видеть леса за деревьями, склонны буквоедствовать и мелочно придираться (говорю как факт, а не чтобы подразнить/обидеть). Увидев что-то, что является (на ваш взгляд) неверным использованием термина, вы перестаете читать и начинаете демонстрировать ерундицию. В последнем слове нет опечатки, кстати - именно так оно и пишется в данном случае.

А с чего вам показалось что у меня дотнет эмулируемый? Музыкой навеяло? Я вообще-то говорил об вирутальных машинах изначально (жрущих по сути те же ресурсы, что сама прога).

К слову, "на" компиляторах может и не пишут, но вот "под" пишут. Устойчивый сленг - собственно, черезчур опасливое обращение со сленгом и выдает в вас "эх, молодешшшь". Хотя в эру кросплатформенности уже и "под" не пишут, потому что это как раз означает - вот оно - аппаратную или системную ориентированно кода, раз он использует даже особенности компилятора.

Повторюсь - есть деревья, а есть лес. Это уж не говоря о том, что вы, нелюбезный, влезли в тему, где я общаюсь с явно непрограммистом, и влезли с претензией - как потом стало понятно - что я не вывалил на него необязательных исключений и оговорок.

Приписка вполне в духе "на компиляторах не пишут". Ну и то верно - зачем менять лошадку, которая всегда выигрывает, да?

Резюме:
Если по сути, повторю простую фабулу, настолько простую что даже не знаю как ее "доказать" - грамотно написанный аппаратно-ориентированный софт, транслированный в машинный код в предназначенной для него среде - ПРАКТИЧЕСКИ ВСЕГДА быстрее, компактнее и проще, чем столь же грамотный кросплатформенный, но ВКУПЕ с необходимыми для запуска вспомогательными средствами (если слово интерфейс не нравится).

По вышеизложенному есть возражения, или только придирки к пунктуации?

Date: 2015-01-13 03:01 pm (UTC)
From: [identity profile] serpentthegreen.livejournal.com
>Ок. Отвечаю по сути - это вам показалось, что я смешиваю.
"Как пример - в дотнете отказались от выделения и освобождения динамической памяти вручную. С одной стороны это помогает мультиплатформенности, с другой неизбежно ведет к нагромождению унифицированных апи, жрущих ресурсы."

Управление памятью не помогает мультиплатформенности и не ведёт к нагромождению унифицированных API.

>Увидев что-то, что является (на ваш взгляд) неверным использованием термина, вы перестаете читать и начинаете демонстрировать ерундицию.
>Устойчивый сленг - собственно, черезчур опасливое обращение со сленгом и выдает в вас "эх, молодешшшь"

Есть устоявшиеся термины и определения. Вы, конечно, вправе использовать их как вам угодно, но не обижайтесь, что вас не хотят понимать.

>Резюме:
>Если по сути, повторю простую фабулу, настолько простую что даже не знаю как ее "доказать" - грамотно написанный аппаратно-ориентированный софт, транслированный в машинный код
>в предназначенной для него среде - ПРАКТИЧЕСКИ ВСЕГДА быстрее, компактнее и проще, чем столь же грамотный кросплатформенный, но ВКУПЕ с необходимыми для запуска
>вспомогательными средствами (если слово интерфейс не нравится).
>По вышеизложенному есть возражения, или только придирки к пунктуации?

Что вы понимаете под кроссплатформенным кодом ?

Date: 2015-01-13 03:26 pm (UTC)
From: [identity profile] ab-dachshund.livejournal.com
Ну да, об этом я и говорил как о лесе и деревьях. К нагромождению ведет кросплатформенность, а не собственно переосмысление malloc. По сути - прямой доступ к памяти мешает кросплатформенности. Неужели будете с этим спорить?

Если бы вы больше думали о том, что хочет сказать собеседник, а не отвлекались на мысли о том, на чем еще его "подловить" - вас никто бы не называл мелочным занудой.

Я на вас не обиделся. Чувства у меня к вам сложные и многокомпонентные, и одним словом резюмируются скорее как "раздражение", чем как "обида".

Кросплатформенный - это не использующий напрямую аппаратные особенности платформ. Например, если у вас в сишной программе хитровывернутые вставки ассемблера x86. Или если вы получаете прямой доступ к стеку для манипуляций с адресом возрата. Или если вы преобразуете физический адрес в целочисленную переменную для вычислений какой-нить ереси, а потом обратно. Если ваш алгоритм оптимизирован для конкретной длины слова. Или если еще что-нибудь столь же стильное. О, например вы используете сопроцессоры на графической плате. Хотя тут я на тонком льду - с кудой я не работал, но теоретически это должен быть аппаратнозависимый язык.

Я думаю вам будет понятен такой пример - если ваши самолетные дела имели какие-то уникальные компоненты (ну не знаю, контроллер обратной связи, пинающий кресло пилота при перегрузках) и вы в софте напрямую обращались к этому контроллеру - то этот софт аппаратнозависимый. Чтобы его портировать на PalmOS вам понадобится эмулятор этого пинального инструмента. Какой-то драйвер лишний, например. Так как этот эмулятор будет задействать центральный проц, а не работать как отдельный аппаратный компонент - то его наличие замедлит работу. Либо же вам придется в софте предусмотреть какие-то ветви алгоритма, которые будут работать если устройства нет - увеличение кода. Т.е. экивоки, танцы с бубнами и самоограничения для программиста, нужные для настоящей кросплатформенности, в общем случае ведут к ухудшению работы комплекса.

Так понятнее?

На одном и том же с++ можно написать код, который пойдет почти везде (типа hello, world), а можно такой, который не только под конкретную ос, но и соберется только на конкретной версии компилятора. Только не говорите мне, что ни разу не имели проблем от перетаскивания проекта под новую версию - это плохо характеризует сложность вашего софта.

Date: 2015-01-13 06:12 pm (UTC)
From: [identity profile] serpentthegreen.livejournal.com
>К нагромождению ведет кросплатформенность, а не собственно переосмысление malloc.
Тут вопрос насколько вы пуританин в данном вопросе. Там можно докатиться что malloc (кросплатформенный, кстати) и CRT вообще -- "нагромождение".
Синтаксис разный, но и в NET и в С дёргается (из процессорозависимого кода) runtime, который содержит реализацию выделения памяти для данной платформы.
Количество слоёв одинаковое. У .NET просто есть отдельный процесс, который периодически говорит "а вот тут -- free". Да, отнимает ресурсы, но он не между памятью и софтом, а рядом.

>По сути - прямой доступ к памяти мешает кросплатформенности. Неужели будете с этим спорить?
В общем виде -- не буду.
Но замечу, что с malloc + аккуратная арифметика указателей проблем не вызывали. Код при этом исполнялся на разных аппаратных платформах.

>Кросплатформенный - это не использующий напрямую аппаратные особенности платформ. Например, если у вас в сишной программе хитровывернутые вставки ассемблера x86.
У таких оптимизаций есть один нехороший нюанс -- например внезапно выясняется, что на Intel такая вставка выполняется вдвое быстрее, а на AMD в 20 раз медленнее. И прочие проблемы с поддержкой.
Виртуалки опять же ... Да и учитывая, что я никогда не буду знать как нюансов работы процессоров лучше чем разработчики backend'a под этот процессор -- я предпочту оставить на C. Оптимизация на уровне алгоритмов -- пожалуйста, но не уровне машинных кодов.

>Я думаю вам будет понятен такой пример
Понятен, но я не согласен с выводами и с подходом для данного примера. У меня есть система. Код условно делится на две части. Зависимый от платформы и независимый от платформы. Зависимый от платформы код выносится в отдельные модули. При переносе на другую платформу эти модули меняются на другие, работоспособные/оптимизированные для данной платформы, линковка к другим либам, условная компиляция -- не суть. Не нужно никаких ветвей в коде, отдельных эмуляторов и прочей байды, просто другой makefile.

Я понял ваш подход (optimización o muerte) и ваши претензии к современным программистам/средствам разработки. Он даст хорошие результаты, когда вариантов программно-аппаратной части 1-2.
Но в современном мире даже в одном сегменте х86 уже накопился и растёт значительный зоопарк вариантов тех же расширенных инструкций итд, а у большинства программистов нет возможности контролировать, на чём этот код будут запускать -- так что с вашим подходом разработка для рынка "не взлетит". И дело тут не в ленивых программистах, перетаскивающих "стандартными средствами компиляторов софт, разработанный для "больших" компов.", софт получится стоимостью как золото по весу программистов. Компромиссы, компромиссы.

Date: 2015-01-14 05:56 am (UTC)
From: [identity profile] ab-dachshund.livejournal.com
Если "прямой доступ к памяти" ограничить операцией ++ к указателю - то да, проблем не будет. Потенциальную проблему можно исключить двумя способами - или клятвенно обязать программиста не делать фигни, или ограничить его синтаксисом, проверить угрозы на этапе компиляции и постоянно следить операционкой.
Юмор в том, что махинации с памятью нам понадобились не просто так, мы что-то же имели ввиду. Это была некая свобода для программиста. Свобода, которой теперь не будет. Не говоря уж что инструменты ограничения этой свободы сами жрут ресурсы.

Диллема имени use strict в перле, если понимаете.

Блин, да - ДА. Я именно об этом и говорю, когда упоминаю АППАРАТНООРИЕНТИРОВАННЫЙ КОД. Неужели само словосочетание не навело на мысль, что оно заточено под конкретную даже не ОС, а сочетание ОС и железа такого-то производителя такой-то модели. Если вы _знаете_ что там есть багофича, которая позволяет ускорить конкретную работу в 20 раз - вы ее используете и получите бешенный профит. Но при этом накроется мультиплатформенность. Итого - мультиплатформенный софт на этой конкретной машине будет - по вашим же оценкам - в 20 раз медленнее, чем специально заточенный под нее. О чем я говорил с самого начала?

Я могу вспомнить момент появления математических сопроцессоров (да, вот такой я старый). Когда наши выстраданные алгоритмы пошли на помойку просто потому что с добавкой 287 сопроцессора без всяких хитростей получали прирост производительности в разы. Ну и зачем мучаться и придумывать что-то ночами, когда можно просто попроситься обсчитать матрицу на том новом компе в соседней комнате? Я специально вам привожу примеры из советского детства, не для того чтобы вы "поразились программе с пищалкой", а чтобы завуалированно сказать "подрастешь - поймешь". Напрямую сказать не могу, как раз потому что понимаю - тенденция к кросплатформенности и отказу от низкоуровневой оптимизации переживет не только такого старого волка как я, но и детишек типа вас.

Это я к тому что да, вам не пригодится низкоуровневая оптимизация, разве что появится сверхминиатюрный источник питания, позволяющий создавать сети из микрокомпов не сложнее контроллера и не дороже самореза, для которой понадобится лаконичный софт. Или цивилизация рухнет и придется переходить на механические компы и лучину - ну или вы найдете очень специфическую область деятельности. Но ниша последнего неуклонно сокращается.

Я нигде не говорил о коммерческом успехе моего подхода, кстати. Наоборот. Я понимаю, что будушее за тяп-ляп разработками, дешевой памятью и дешевым временем. Даже оптимизация на уровне алгоритма почти не востребована, дешевле купить комп помощнее, чем платить программеру. В 80х все думали о оптимизирующих компиляторах, которые позволяют сами исправлять ляпы программиста. Сейчас если оптимизация в компиляторе и есть - она по дефолту отключена, а если и включить, то максимум она выносит инварианты из цикла.

Это, кстати, если вы еще не поняли, большая беда для программеров - это означает что даже если вы можете написать хороший алгоритм, вас все равно заменят индусом, потому что а) и так работает и б) смета дешевле. Планка знаний и опыта для доступа в профессию все снижается. Скоро малые дети смогут писать софт за бочку варенья и коробку печенья, а тем, кто хочет получить за труд что-то существенное, придется переквалифицироваться в управдомы. Помятите мое слово.

Date: 2015-01-14 07:24 am (UTC)
From: [identity profile] serpentthegreen.livejournal.com
Извините, нет желания продолжать с вами разговаривать.

У вас здравые мысли связаны с неуместным апломбом, чёрно-белым мышлением и искажённым представлением о реальности в современной разработке софта.

Так что всего доброго.

Date: 2015-01-14 07:29 am (UTC)
From: [identity profile] ab-dachshund.livejournal.com
Если у меня оно черно-белое, то у вас явно розовое.

Вырастайте из этих очков поскорее.

Profile

engineering_ru: (Default)
Инженерия

December 2025

S M T W T F S
 123456
78910111213
14151617181920
2122232425 2627
28293031   

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Mar. 7th, 2026 10:24 am
Powered by Dreamwidth Studios