Как стать автором
Обновить

Комментарии 60

А ведь всё как у людей! Приятно

Самое грустное в этой части то, что человек (чаще программист), привыкший общаться с компьютером на уровне столетий, когда реализует свою задачу, не задумывается, выполняется его код за 1 месяц или за 10 лет — на уровне столетий эту разницу совсем не видно. Про premature optimization прошу не писать, это всё известно. Тут как раз суть в том, что все привыкли как раз НЕ оптимизировать заранее, а потому чаще пишут неэффективно. А потом при увеличении например входных данных в 10 раз разница между 10 лет и 100 лет уже становится ощутимой (хотя между 1 месяц и 10 месяцев она была бы не видна, и это было бы более эффективным решением).

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

Мы наблюдаем общество, которое все больше зависит от машин, но при этом использует их все неэффективнее. (c) Douglas Rushkoff

Это применимо к очень многим вещам, к сожалению.
Если бы мы выжимали из всего максимум эффективности, то вы бы до сих пор ковыряли землю очень эффективной палкой.
Желание получить максимум результата за минимум времени приводит к новым технологиям.
Отличный пример это Intel, пока они выжимали 14нм тех процесс, TSMC обогнала их по всем фронтам.

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

они просто застряли с 14нм, не в силах освоить и наладить более прогрессивные техпроцессы

Так в этом и проблема, получив проблемы при переходе на новый тех процесс, они вместо того что бы тратить ресурсы на новую технологию начали наращивать эффективность старой. И в итоге отстали от всех.
А смысл остаётся тот же, доводить эффективность до максимума не эффективно.
Интел давно похоронили x86, но всплыл amd64. Который убил итаниум и вынудил интел тыкать палкой в труп ещё 20 лет. Кушать-то хоцца.

Так когда данные вырастут в сотни раз, тогда и оптимизировать можно начинать. Код есть. Изначально надо решить задачу, можно вообще на питоне полчаса считать, получить результат и забыть о коде. А оптимизировать можно полдня чтобы оно считалось не полчаса а минуту, но в итоге времени потрачено будет в 10 раз больше.

Проблема в том, что программисты переходят на более высокоуровневые языки, вплоть до интерпретируемых. Это увеличивает скорость разработки и снижает количество ошибок, но уменьшает возможность оптимизации. Пустое окно с кнопкой на Дельфи может скомпилироваться в мегабайтный файл, и до пары кБ, как у краков с музыкой и анимацией, его никак не соптимизировать…

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

Интерпретируемые языки увеличивают количество ошибок, а не снижают.

Пустое окно с кнопкой на Дельфи может скомпилироваться в мегабайтный файл, и до пары кБ, как у краков с музыкой и анимацией, его никак не соптимизировать…

Написал десятки кряков с музыкой на delphi, с использованием winapi — файлы были по 10-20 КБ.

НЛО прилетело и опубликовало эту надпись здесь

Да, слышал, но никогда не пользовался. Музыку какую-то сам писал, какую-то воровал. Для Delphi был модуль воспроизведения XM-треков, который добавлял программе всего пару килобайт.

Самое грустное в этой части то, что человек (чаще программист), привыкший общаться с компьютером на уровне столетий, когда реализует свою задачу, не задумывается, выполняется его код за 1 месяц или за 10 лет — на уровне столетий эту разницу совсем не видно.

Почему грустное? Просто особенность работы, обусловленная взаимодействием человека с техникой. Нет разницы, если кнопка в бизнес-приложении реагирует на мышь за 0.1с или 0.001с. И в тоже время есть разница, когда 1 доступ к диску занимает 0.1с или 0.001с. В первом случае человек не способен генерировать нажатия кнопки быстрее, чем раз в ~1c, во втором - 1000 чтений диска желательно завершить раньше (и тут всплывает вопрос, почему современные компьютеры жрут память. краткий ответ: кэширование).

Тут как раз суть в том, что все привыкли как раз НЕ оптимизировать заранее, а потому чаще пишут неэффективно.

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

babayota_kun


Тут еще неплохо было бы привести аналогичное сравнение для разных типов обращений — обращение к кешу процессора такого-то уровня, обращение к данным в оперативной памяти, обращение к данным на SSD диске NVME, обращение к данным на SSD диске SATA, обращение к обычному HDD, обращение по локальной сети (один сетевой запрос), обращение по Интернету (один сетевой запрос).

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

L1 cache is a beer in hand, L3 is fridge, main memory is walking to the store, disk access is flying to another country for beer.

источник

А регистры — это когда пиво уже во рту или в желудке?

Последнее слишком оптимистично. Хотя если начать с планирования отпуска на следующий год...

Надо уже промежуточную задержку для SSD добавлять. Поездка в пригород?

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

http://femto.com.ua/articles/part_2/2483.html

Только у человека все намного медленнее.

Скорость распространения информации в магистралях около 100м/с, в периферии около 2м/с, это при общей длине всех путей в сотни тысяч километров. Не удивительно, что до некоторых только на второй день доходит.

Частота в магистралях до 500гц, в периферии в основном сильно ниже.

человек за это время может пешком дойти до сервера и вернуться!

Кажется пора писать очередные поправки к RFC 2549…

Важно не то, что там происходит все очень быстро, А кто хозяин всего этого процесса. Весь этот титанический пласт уровней абстракций над быстрыми низкоуровневыми событиями, именуемый Человеком. Без наблюдателя все эти события никому не нужны и не интересны, и только человек (пока) умеет копаться в этих пластах, открывать закономерности, удивляться, строить новые уровни и вкладывать новые смыслы.

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

А ведь в «сеттинге» статьи статьи можно бы было попытаться наглядно донести понятие алгоритмической сложности (сколько строителей понадобится для постройки пирамиды высотой 1 километр? а 2?), а не просто удивлять аналогиями :3.

Напишите об этом статью, будет интересно

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

В большинстве случаев операционной системы там нет, потому что "программист" (на самом деле бывший электронщик) просто не осилил -RTOS и в итоге руками, коряво и непереносимо реализовывал то, что есть в -RTOS / сторонней бибилиотеке

RTOS сейчас и операционной системой-то не назовешь. Она прямая, плоская и открытая, делает всё очень быстро и, как правило, не мешает.

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

В большинстве случаев оно там тупо не нужно, и лишь сожрёт драгоценные ресурсы.

Зачем пихать ОС туда, где она не нужна? Во многих случаях машина состояний гораздо удобней любой ОС, особенно если в системе полно процессов, которые нельзя прерывать, или которые зависят от других процессов, поэтому должна быть жёстко заданная последовательность обработки. В РТОС это решается костылями, но зачем вначале пихать в программу костыль в виде РТОС, а потом подпирать его со всех сторон другими костылями, чтобы оно работало по ТЗ а не по своему разумению?
Зачем пихать ОС туда, где она не нужна?

Во всех случаях, когда исполняется несколько процессов нужна ОС, иначе: "руками, коряво и непереносимо реализовывал то, что есть в -RTOS"


В РТОС это решается костылями

Нет, в РТОС это как раз решается стандартными средствами, собственно это и есть одна из ее главных задач. Увы, большинство "программистов" микроконтроллеров даже это осилить не в состоянии.

А можно bare-metal 4 ядерные армы (апельсинку, например) прогать, если хочется хардкора)

Что приятно с контроллерами - все полностью под контролем до такта.

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

Это настоящий временной микроскоп.

Какая-то у вас допотопная ОЗУ, если обращение к ней занимает 120нс. У самых свежих модулей ~35нс. Даже у меня с моей пожилой DDR3-1600CL9 55нс

Да, верно, писал как помнил, не загуглив относительно свежие числа. В то время, когда меня интересовал вопрос (и кода я нашёл ответ и запомнил его) memory reference latency была около 100нс.

Внесу правку в статью, спасибо!

Не вносите. На ноутбуках до сих пор все печально, особенно на АМД.

Но если перевести это в "компьютерное" время, то это всего-то час труда раз в пару месяцев.

Работа не бей лежачего, получается

Еще и столетия телеметрии…
А запуск Windows, полагаю, с момента строительства Египетских пирамид ещё не завершился. Что эта винда там делает всё это время ??

У Руссиновича в Windows Internals можно почитать. В 6-й редакции это 13-я глава: 25 страниц описания процесса загрузки. Большую часть времени занимает 38-й шаг второй фазы загрузки - обнаружение и инициализация устройств.

Ждет караванов из Нового Света с камнями и папирусом с описаниями привезенного. Каждый раз, когда ей что-то понадобится с диска.

Интересно. Самая шокирующая фантазия: мир компьютера детерминирован, а все неопределённости приходят из внешнего мира

из подобных сравнений

Скот Мюллер. "Модернизация и ремонт ПК"

Вам, возможно, приходилось читать книги или статьи, в которых для описания взаимо­действия головки и диска используется аналогия с "Боингом-747", летящим в нескольких метрах над землей со скоростью 800 км/ч. Я сам в течение нескольких лет частенько к ней прибегал на упомянутых семинарах, но никогда не задумывался над тем, насколько точно она соответствует современным накопителям.
Правда, сравнение головки с летящим самолетом всегда казалось мне некорректным. Она ведь никуда не летит, а плавает на воздушной подушке, которая создается на поверх­ности вращающегося диска.
Правильнее было бы сравнить ее с судном на воздушной подушке. Благодаря спе­циальному профилю головки толщина создающейся воздушной подушки автоматически поддерживается постоянной. Иногда такой способ взаимодействия двух подвижных объ­ектов называют воздушной подвеской.
Пересчитаем теперь все геометрические размеры накопителя в соответствии с мас­штабом, при котором величина зазора между диском и головкой составит точно 5 мм. Это означает, что все соответствующие числа необходимо умножить на 333 333 — именно во столько раз 5 мм больше, чем 15 нм.
Представьте себе эту головку: при таком увеличении ее длина составит около 410 м, ширина — 325 м, а высота — 100 м (это приблизительно размеры небоскреба Sears, положенного на бок). Перемещается она со скоростью 9 187 км/с на расстоянии всего лишь 5 мм над землей (т. е. над диском) и считывает биты данных, промежутки между которыми равны 2,16 см. Эти биты данных расположены на дорожках, расстояние между которыми составляет всего лишь 29,9 см.
Скорость перемещения этой гипотетической головки даже трудно себе представить, поэтому я приведу конкретный пример. Диаметр Земли составляет 12 742 км, т. е. длина околоземной орбиты, проходящей на расстоянии одного дюйма от поверхности, будет равна приблизительно 40 000 км. Таким образом, развивая скорость 9 187 км/с, эта головка совершит виток вокруг Земли меньше чем за пять секунд.
Не правда ли, хочется воскликнуть: "Видел чудеса техники, но такие!..". И действи­тельно, современный жесткий диск — это настоящее чудо техники! Как видите, пример с авиалайнером оказался лишь жалким подобием того, чт. е. на самом деле (не говоря о его некорректности с точки зрения физики).

Еще была аналогия: представьте что в одном миллиметре - год. Тогда октябрьская революция от на на расстоянии метра. Петр I жил в трех метрах. Христос родился в двадцати метрах. Пирамиды в Египте построили где-то в 50 метрах от нас. Человечество зародилось уже на расстоянии пары километров (200к лет назад). А когда же жили динозавры? 660 километров, Карл! А жизнь зародилась не менее чем в 37 000 км от нас...

представьте что в одном миллиметре — год

Наверное все таки год равен одному сантиметру )
А вселенная образовалась на расстоянии 138000 км.

Вспомнился фильм Она (Her), когда ИИ девушка - операционная система, сказала Теодору что одновременно общается ещё с десятком тысяч таких же как он в этот самый момент.

Да, для ИИ люди будут как Бонсаи )

НЛО прилетело и опубликовало эту надпись здесь
Компьютер ничего не воспринимает и не осознает, статья — просто бесполезный мысленный эксперимент

Вы программист 1С? :)

Нет, JS-ник.

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

И это только процессор. Видеокарты еще быстрее. Интересно сравнить современные и новые модели. Иногда даже не задумываешся, как быстро все стало. В том числе и в плане алгоритмов.

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

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

babayota_kun
Я нашел-таки эту табличку (правда от 2012 года):


Latency Comparison Numbers (~2012)
----------------------------------
L1 cache reference                           0.5 ns
Branch mispredict                            5   ns
L2 cache reference                           7   ns                      14x L1 cache
Mutex lock/unlock                           25   ns
Main memory reference                      100   ns                      20x L2 cache, 200x L1 cache
Compress 1K bytes with Zippy             3,000   ns        3 us
Send 1K bytes over 1 Gbps network       10,000   ns       10 us
Read 4K randomly from SSD*             150,000   ns      150 us          ~1GB/sec SSD
Read 1 MB sequentially from memory     250,000   ns      250 us
Round trip within same datacenter      500,000   ns      500 us
Read 1 MB sequentially from SSD*     1,000,000   ns    1,000 us    1 ms  ~1GB/sec SSD, 4X memory
Disk seek                           10,000,000   ns   10,000 us   10 ms  20x datacenter roundtrip
Read 1 MB sequentially from disk    20,000,000   ns   20,000 us   20 ms  80x memory, 20X SSD
Send packet CA->Netherlands->CA    150,000,000   ns  150,000 us  150 ms

Notes
-----
1 ns = 10^-9 seconds
1 us = 10^-6 seconds = 1,000 ns
1 ms = 10^-3 seconds = 1,000 us = 1,000,000 ns

Доступна тут:
https://gist.github.com/jboner/2841832

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

Публикации

Истории