Вершина нашего развития [Машины и мы 01]

[mikhai1-t.livejournal.com]

Оригинал взят у mirvn в Вершина нашего развития [Машины и мы 01]

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

Расшифровка данных 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 квадратных километров проводами и микрофонами. Что фура с проводами на картинке ниже в этом случае должна быть заменена карьерным грузовиком, а может и целым железнодорожным составом. А количество укладчиков будет сопоставимо с армией КНДР. Да, вы правы, правы.

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

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

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

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

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

Совместно с plaksiva9tr9pka

Comments

[ab-dachshund.livejournal.com]

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

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

Помните такую игрушку конца 80х - Elite? Короче, 3-д симулятор космического корабля "от первого лица", с стрелялками, маневрированием, апгрейдом и даже сбором обломков, плюс элементы РПГ и экономической стратегии (если не путаю более тысячи планет с различной экономической обстановкой). И все это в 200 килобайтах (КИЛОбайтах!) и шло на XT. Сейчас игрушка с такой же убогой графикой и геймплеем потребовала бы мегабайты оперативки и минимум пентиум, а уж дискового пространства съела бы не меньше, чем одна фотка из отпуска.

Я видел и играл - да что там, про это писали в "Науке и Жизни" - программу "Гонки" для МК52. Вы знаете, что такое МК52? Калькулятор-переросток. 100 команд "уровня ассемблера" - положить в регистр, провести операцию над регистром, передать управление. Один экран на 12 символов. И на этом железе какой-то сумрачный гений сделал гонки - машинка ехала по извилистой дорожке, объезжала препятствия. А знаете, как она поворачивала? Переключателем "градусы-радианы". Вы только представьте грандиозность задачи и "плотность goto".

Сейчас такого не пишут.

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

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

[serpentthegreen.livejournal.com]

>просто стандартными средствами компиляторов портировать софт, разработанный для "больших" компов.

Рука. Лицо.

[ab-dachshund.livejournal.com]

Отстали от жизни. Гуглите "мультиплатформенность".

[serpentthegreen.livejournal.com]

Я как раз в курсе, спасибо.
Компиляцией только "hello world" переносится.

[ab-dachshund.livejournal.com]

Ну так не отказывайте другим в праве быть в курсе.

[ab-dachshund.livejournal.com]

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

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

[serpentthegreen.livejournal.com]

GC приводит к нагромождению API ?
Вы делаете мне смешно. Продолжайте.

[ab-dachshund.livejournal.com]

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

[serpentthegreen.livejournal.com]

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

Как сборка мёртвых объектов приводит к "нагромождению унифицированных апи" ?

Вы не знаете что такое API ?

[ab-dachshund.livejournal.com]

Вы какое-то конкретное API имеете ввиду, а я говорю про "апи", как многоуровневые интерфейсы между конечным кодом и операционкой, а в последствии и железом. Вы не в состоянии заметить разницу в РАЗМЕРЕ испольняемого кода между "hello world", написанном на платформенноориентированном компиляторе и в многоплатформенной среде плюс собственно эмулятор? Ну простите - тогда не удивительно что вас смешат очевидные вещи.

[serpentthegreen.livejournal.com]

Нет, я не имею в виду конкретное API.
Я имею в виду, что управление памятью и программные интерфейсы -- разные вещи.
Были LISP - машины с аппаратно реализованной сборкой мусора.
Тот же .NET сейчас можно использовать для разработки (Micro Framework) для аналога adruino. Без винды и прочих "многоуровневых интерфейсов". 120 mhz, 60 килобайт оперативы.
И управление памятью влияет только на удобство разработки, но не на кроссплатформенность.
ANSI C -- реально кроссплатформенный, вплоть до плисов. Вот только управления памятью в нём нет.

Ну и да, на компиляторах не пишут, это так, для справки.

[ab-dachshund.livejournal.com]

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

Ты пойми простую вещь - когда ты пишешь ("не на компиляторе") прогу под конкретную машину, ты можешь использовать много всяких вкусностей (если знаешь их, конечно). Багофичи. Например, я однажды (в детстве) написал прогу (как бы ты сказал "не на ассемблере"), которая играет на бипере мелодию. Я задавал частоты и через пустые циклы регулировал длительность звучания. Методом тыка добился удачного исполнения. Программа, если не считать отладки - проще некуда. Естественно, на другой чуть более шустрой, машине она звучала быстрее, потому что циклы исполнялись быстрее. Сейчас бы она слилась в один писк, даже если бы запустилась. Это я к чему. Вот у меня была простая, незатейливая прога в сотню байт, использующая аппаратные свойства машины. Чтобы прога работала на всех машинах даже с той же операционкой, мне нужно было разобраться с таймером, что сильно усложнило код. Понимаешь? То есть ты либо используешь багофичи конкретной архитектуры и на этом выезжаешь, либо громоздишь универсальные вещи - которые практически всегда больше и медленее.

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

Кстати, в этом смысле написание проги на одном и том же паскале под borland версий 3 и 4 принципиально отличалось. Но ты, походу, недостаточно олдскулен для этого - угадал?

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

[serpentthegreen.livejournal.com]

>Твоя фраза про "на компиляторах не пишут" - это апофеоз мелочности и бессмысленности всех твоих замечаний.

Это апофеоз вашей безграмотности.

>Ты пойми простую вещь
[Онанизм на олдскульность поскипан]

Я участвовал в разработке авионики. Системы реального времени для самолётов. С жёстким выдерживанием циклограммы. Так что ваши "мелодии" меня не впечатляют.
Но не сползаем с темы. Разницу между API и GC уяснили ?

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

Про front-end и back-end у компиляторов вы не слышали, да ?
Модульность ПО там, прочие "ужасные" вещи ?

[ab-dachshund.livejournal.com]

Чувак, у тебя есть что возразить по теме, кроме "на компиляторах не пишут" и "а я тоже писал программы"?

Походу нет.

Постарайся изложить свою позицию не в терминах "а ты как я надеюсь не знаешь что" и "вот тут у тебя не там запятая". Ты против чего конкретно возразить пытаешься? Против какого утверждения конкретно?

Ты хочешь оспорить то, что кроссплатформенный код (и "на компиляторе" и исполняемый) в среднем в разы более громоздкий (медленный и объемный) чем аппаратно-ориентированный? И ты после этого хочешь меня убедить, что писал что-то под специфическое оборудование? Ты не обращался там напрямую к харду ни разу?

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

Не тупи, короче.

[serpentthegreen.livejournal.com]

(Терпеливо)
Разницу между API и GC уяснили ?

[mikhai1-t.livejournal.com]

Оптимизация не бесконечна она не позволит вам сохранять 257 разных значений в одном байте. Если у вас алгоритм уже самый оптимальный для задачи допустим C*O(n) оптимизация воюет с константой C но до нуля она не опуститься не каким образом а если он не ноль то это означает, что вам нужно в какой то момент более мощный компьютер. Ради упражнения попробуйте написать игрушку Elite на железе 80х только что-бы там было не 200 систем а 200000.

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

[ab-dachshund.livejournal.com]

А 257 одинаковых значений - вполне. Или 257 разных - но в паре байт. Да, не все последовательности из 257 разных значений можно успешно сархивировать - но какие-то можно. Или можно не так успешно, скажем в 25 байт. Это вопрос математики, а следовательно - алгоритмизации и трудозатрат программиста.

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

Т.е., если вы дадите _мне_ выбрать последовательность - я напишу вам алгоритм, где все эти числа выводятся из одного байта "затравки".

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

Вы неверно ставите задачу (это уже про Нокию). Да, заставить на старой нокии и на айфоне с одной скоростью работать _один и тот же алгоритм_ нельзя. Но кто говорит, что это один и тот же алгоритм? В конце концов, мы смотрели кино на виндовсфоне так же, как сейчас смотрим на айфонах. Хотя процессор был слабее. Как мы этого добивались? Потерей качества, разрешения, меньшим сжатием (экономичными кодеками). То есть программными средствами, по сути.

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

Вы не читали "Difference engine" Гибсона и Стерлинга? Там была такая интересная штука - кинотроп. Устройство из поворачивающихся кубиков с разными цветами на гранях - наподобие старых табло на вокзалах. На паровой тяге, с шестернями. И там было хоть и всколзь, без математических деталей, но описаны ухищрения тогдашних программеров, как на такой простой машине показывать мультики. Вот это - задачка для математика и алгоритмиста.

[mikhai1-t.livejournal.com]

У меня 257 разных значений то, что 200 значений вы сохранить я знаю но мне это не поможет. А пара байт это уже умножение необходимого железа на 100%. Так, что мы и пришли к тому с чего начали железо ограничивает ваши возможности. И я вам специально дал тривиальный пример. Современный фильм нельзя посмотреть на железе 80х и даже 90х годов по тем-же причинам почему невозможно положить 257 разных значений в один байт.

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

[ab-dachshund.livejournal.com]

Что такое "значения"? У вас есть 257 разных чисел, которые вам кто-то дал? Или это 257 значений некоей параметрической функции? Понимаете - я к тому что вам на самом деле не обязательно прям их хранить как 257 байт или сколько вам там нужно для этих значений. Вы можете их или сжать или вообще аппроксимировать. Ну, для 257 конечно это особого смысла не имеет, но поверьте - просто тупо их хранить в массиве совсем не единственное решение. Я уж не говорю что их не обязательно размещать в быстродоступной регистровой памяти (которой вообще кот наплакал - байт 20), или даже в оперативной памяти. Согласитесь, добавить гиг оперативки, гиг дискового пространства и гиг ленты стримера - это принципиально разные даже по деньгам решения. Да, увеличить число регистров в 20 раз - это полностью поменять архитектуру. Где бы мы были, если бы все хранили только в регистровой памяти.

Это вы не понимаете, что есть и такие алгоритмы, которые _можно_ улучшать. И поймите, что алгоритм - это еще не софт. Одну и ту же сортировку массива пузырьком можно написать быстро, а можно натупить так, что хоть застрелись. И не все упирается в данные и алгоритмы. Есть еще параллельные вычисления. Слышали про язык cuda и платы тесла с 4мя, что ли тысячами процессоров? То есть у вас сейчас четырехядерный проц и вы считаете себя крутым перцем - а там на одной плате за условно триста баксов - четыре тысячи(!) ядер. Конечно, они слабенькие, большая часть даже не может оперировать числами с плавающей точкой. Но эти ваши "доказанно навороченные" алгоритмы можно написать, допустим, неоптимально, зато для параллельных вычислений. Понимаете? Новое измерение для оптимизации.

[mikhai1-t.livejournal.com]

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

Я ведь не утверждаю, что абсолютно всё написано оптимально, да можно многое оптимизировать особенно в коммерческом софте, но у любой оптимизации есть свой предел.

[ab-dachshund.livejournal.com]

Стоп, уже неверно. Задача явно шире - у вас есть 257 поставщиков бинарной информации, с которых вы собираете (отслеживаете) бинарные значение - но опять же не просто так, а с какой-то частотой? Вырожденный случай одного наблюдения - без всякого сжатия помещается в 32 байта, как вы понимаете. То есть вы тратите не по байту (и тем более слову, не говоря уж о допустим хешированном сегментированном списке переменных с плавающей точкой, сделанном за пару секунд и одну строчку кода на стандартном контейнере STL) на одно значение, а упаковываете их по восемь на байт. Стандартных контейнеров с побитной упаковкой нет - а значит надо писать и отлаживать, а это лень и дорого, потому ну нафиг, возьмем STL, подумаешь 257 слов?

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

Ну и так далее. Я думаю, я вам показал, что использовать, скажем, массив из 257 двухбайтных слов для хранения однобитных значений - бессмысленно. А ведь именно так все сейчас и делают, когда память дешева.

Вообще - бессмысленно невереное слово. Неэкономично в плане памяти, но очень экономично для сметы разработки.

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

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

Опять же не забывайте, что если делать быстрый и экономичный софт, то никто не купит вам новый комп. И наоборот.

[mikhai1-t.livejournal.com]

Ну вот почему вы хотите рассказать мне какая у меня задача :) ? Я специально выбрал задачу так чтобы было очевидно, что оптимизация не может изменить фундаментальные вещи. Я хочу постоянно знать состояние всех 257 флагов которые помечают мне 257 наличие/отсутвие объектов, самое оптимальное решение — это выделить 2 байта памяти, и в один байт вы это не как не положите уж как не старайтесь. Всё что вы описали это как можно решить эту задачу менее эффективно, да я не спорю можно и часто так решают. Но в действительно серьёзных аппликация всё будет вылизано оптимально, те вычисления, которые запускаться на суперкомпьютерах это очень оптимизированные программы.

[ab-dachshund.livejournal.com]

Я сужу о задаче с ваших слов, не более. Почему для значения 1 или 0 вам нужно аж два байта? В два байта можно поместить 64 тысячи значений или 32 тысячи со знаком. Вы путаете монетку с пуговкой. Вы выбрали 257 чтобы превзойти байт, в котором типа 256? Но там речь о числах от 0 до 256 (если без знака), а не о "значениях". На самом деле байт - это восемь бит, каждый от 0 до 1. Если у вас бинарные значения, то при желании вы можете их упаковать туда восемь штук. Для вашего набора - неполных 33 байта.

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

Что, никогда винраром не пользовались?

Вы видимо далеки от области, если правда считаете что программы на суперкомпах сверхоптимизированы или оптимально вылизаны. Это не так (пфф, это вообще не так). Это точно такие же программы, написанные теми же спустярукавашниками, что все остальные. Откуда взяться другим-то? Именно об этом я и говорю - нет ни сил, ни времени на "оптимальное вылизывание", куда проще и ДЕШЕВЛЕ - не говоря что БЫСТРЕЕ - просто сунуть еще один комп в блейд-корзину и тем гарантированно увеличить производительность на сколько-то там процентов.

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

[mikhai1-t.livejournal.com]

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

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

Насчёт супер компютеров вы абсолютно не правы.

[ab-dachshund.livejournal.com]

Да нет конечно, сжатие данных не единственная возможность - хотя и не исследованная до конца банально за ненадобностью. Есть и другие пути. Наверняка есть и такие, которые мы просто не придумали.

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

В вашем примере - уверен что 99.99% программистов для хранения значений от 0 до 257 выберут не просто четырехбайтовый (обычный, а не двухбайтный укороченный) инт, а еще и с одним битом на знак, да и тот засунут в громоздкий контейнер с указателями или итераторами, а то и в унаследованный класс. И не то что не поморщатся - даже не обратят внимания.

Помните "Основание" у Азимова? Основание специально разместили на бедной ресурсами планете и они занялись миниатюризацией. Трантору это было необязательно - ресурсов много и они дешевы, потому они могли позволить электростанцию размером с город или как там.

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

Я помню как купил свой первый хард на гигабайт. За 400 долларов в ценах двадцатилетней давности. Счастлив был как слон - я забекапил туда четыре рабочие машины без сжатия, с операционкой, своп-файлами, копиями дистрибутивов. Сейчас в тысячу раз большая флешка в формате microSD стоит втрое делевше. Смысл ужиматься, устранять дублирование, архивировать? Я могу просто купить еще одну флешку и забэкапить первую. И даже не заметить по бюджету.

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

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