Комментарии 232
210 наносекунд на вызов - вполне, неплохо, хотя всё ещё далеко от line speed. line speed - это такая произвольная, но очень красиво выглядящая цель, пришедшая из сетевой подсистемы. Если у нас сетевой интерфейс работает на 25G, то это 4.8 миллиона мелких пакетов в секунду, то есть каждый пакет надо обрабатывать за 20 нс.
Соответственно софт (даже не связанный с сетью) можно называть line speed, если он такое может. У вас получается line speed для 2х гигабит (с хвостиком).
Еще можно считать поток входящих и исходящих данных. Хорошо выглядит на алгоритмах для валидации/парсинга/генерации текста. Можно сравнивать с пропускной способностью памяти, например
25G (сейчас обычно 10, 40, 100. при 25 переподписка от 2:1, а в сетях Клоса такого стараются избегать) это как правило аплинки на коммутаторах или порты на ТОРах/спайнах. то есть через эти порты проходит агрегированный трафик многих клиентов. обрабатывается он не процессором, а asic`ом. так что сравнение несколько не корректно. к примеру на NGFW трафик обрабатывается именно процессором и разбор трафика с шифрованием там на уровне 200-800Мб. к чему это? если данные передаются в пределах одного ЦОДа то считать line speed есть смысл. если данные передаются на другую площадку по шифрованным каналам - надо уточнять (или замерять) скорости у хостера. может оказаться что нет смысла в глубокой оптимизации кода в стремлении достичь 25Г. например по тому, что вашему серверу доступен всего 1Г из которых реально вы можете использовать 800Мб так как 20% полосы съедает служебная информация сетевого стека. впрочем... зачем программисту разбираться в сетях? ;)
хотите обсудить архитектуру НА ЦОДов? бывает много чего, речь о том, что надо исходить из возможностей имеющейся инфраструктуры, а не заниматься разгоном сферического коня в вакууме. асики на торах обрабатывают от 2Тб/сек. что эта информация Вам дает? Вы начнете оптимизировать весь ваш софт чтобы достичь таких же значений?
очень похоже что Вы теоретик оторванный от жизни. вот уже лет 15 Вам никто сходу точно не скажет на каком именно железе в текущий момент Ваша задача и Ваши данные. если речь об энтерпрайзе который может себе позволить упомянутый сервер с 800Гб интерфейсом и еще 800 серверов.
любая задача имеет цену. имеет смысл исходить только из цены решения задачи. все остальное - бессмысленные фантазии.
асик это асик. никто о нем не думает, - им просто пользуются и 99,9% не знают что это, где, зачем и как оно работает. например Вы. а смотрят на его описание единицы которые понимают для чего и когда это делать.
если Вы не планируете обсуждать исходную тему, давайте прощаться. успехов.
что важно? в стойках с дисковыми полками на всех дисках версия микрокода одинакова как и версия микрокода на полках. на каком диске ваши данные никто не скажет. на хостах в серверных шасси версия микрокода одинакова, как и на шасси в кластере. на каком хосте ваше ПО в текущий момент - надо смотреть по тому что НА и балансировщик гоняют его между хостами постоянно. для высокой доступности версии микрокода выравниваются автоматически ПО управляющим оборудованием. версии микрокода точно известны и доступны к просмотру в интерфейсе управления. рекомендуемы производителем оборудования версии мирокодов указаны в документации. какое отношение фантазии про микрокод имеют к обсуждаемой теме оптимизации прикладного ПО? зачем вообще пытаться выдумывать мифическую задачу (которая, кстати решена десятки лет назад) в области, в которой не работаешь и про которую имеешь крайне отдаленное представление?
началось все с этого: " Если у нас сетевой интерфейс работает на 25G, то это 4.8 миллиона мелких пакетов в секунду, то есть каждый пакет надо обрабатывать за 20 нс. "
я вот не знаю людей у которых дома реальная потребность в таком оборудовании и оно же в наличии и купленное за свои. поэтому у меня не возникал вопрос о том где работает ПО. опять же автор обсуждаемой статьи изначально говорил о приложении которое планируется использовать в ЦОДе.
ну да, если у вас оборудование домашнего или сохо уровня, то сказать где что в общем-то не сложно. но изначально речь вроде как шла об энтерпайзе? ну вот эта фраза автора "Нужно учесть, что вывод этой функции должен быть вычислен менее чем за 500 мс, чтобы она хотя бы попала в продакшен (где нам нужно менее чем за 500 мс выполнить 400-800 вызовов этой функции)." как бы однозначно намекает что используется оборудование и объемы не домашнего уровня.
хотя может быть я ошибаюсь и люди массово используют подобные задачи дома или в организациях 10-20 человек на своем оборудовании из пары серверов с дисками без рейдов уровня отличного от 1/10 или более современных технологий.
При чем здесь «дома»?
при уровне технологий используемых в оборудовании и ПО. я говорил что в НА кластере с включенными DRS и SDRS сказать на каком хосте выполняется ПО в данный момент затруднительно, нужно зайти в консоль управления и посмотреть (и в данном случае микрокод на всем оборудовании будет либо одинаков либо достаточно совместим для работы данных технологий и ваше ПО не увидит разницы). мне ответили что такое возможно. да, такое возможно. но только если у вас нет данных технологий. а это значит что использует что-то более примитивное, рассчитанное на сегмент малого офиса или домашнего использования ("дома"). то же самое относится к системам хранения: если Вы можете точно указать на каком диске ваши данные у вас СХД или рейдов (кроме 1 и 10) просто нет.
я вижу что обсуждение зашло в тупик. уже никто не помнит с чего все началось и все пытаются обсудить что-то совершенно иное, что не все понимают. давайте закругляться - выхлоп от этой беседы какой-то нулевой для всех участников. если кому-то принципиально - считайте что я ничего не понимаю и несу чушь. займемся чем-то более полезным и интересным! ;)
Уже давно нет. Сервер с парочкой 25G стоит 2 бакса в час. Если напрячься, то будет и 4x25.
100G уже более экзотика, но 25G вполне на рынке уже присутствует.
Хороший коммент, плюсанул,
но почему-то мне кажется, что это называется wire speed. Ну или line rate.
Не хватает сравнения с JIT-компилятором (numba).
Numba будет медленее чем реализация на чистом c++. Если говорить про питон, то я бы посоветовал посмотреть в сторону RAPIDS (у них там есть реализация датафреймов как пандас но на gpu), но только если имеется cuda. :)
зы. пару месяцев назад ради интереса я тут потестил как ускорить расчет максимальной возможной просадки используя монтекарло и лучший результат конечно был c++ cuda, но из питона мы можем отлично получить почти такую же скорость... Постить тут не буду, но кому интересно может глянуть на моем ютбчике.
Показательная статья. Представьте, сколько неоптимального кода выполняется на миллиардах устройств каждый день, 24.7 Особенно у питонистов, не юзающих cython?:) Я бы даже обобщил, на все языки. Спрятавшись за абстракциями и оправдывающихся временем программиста.
Не временем. Основная (истинная) задача любого кода - скрытие сложности. Современные системы на многие порядки сложнее старых систем (например 70ого года, когда уже считать научились быстро), и вываливание этого на программиста приведёт либо к вываливанию этого на пользователя (когда вы последний раз выставляли объём оперативной памяти вашего телефона с помощью джамперов?), либо к отсутствию фич. Каких? Например, способности показать одновременно русский и арабский на экране. Или работе в произвольном разрешении экрана на устройствах разных вендоров. Если вы посмотрите на "быстрый старый софт", то там очень много giga (garbage in garbage out) и "действий оператора" (см выше про джамперы с размером оперативной памяти).
Вы готовы вводить адрес начального загрузчика на телефоне каждый раз, когда он "просыпается" в восьмеричном формате?
Отчасти согласен, но поддержка языков и произвольное разрешение, уверен занимает малую часть от производительности современных мобильных и десктопных процессоров. Причина, все же в другом.
Если вы под "поддержкой" подразумеваете потраченное машинное время, то а) оно существенно (вы смотрели сколько стоит отрендерить ненормализованную unicode-строку с помощью ttf-шрифта с субпискельным сглаживанием?)
И б), основное, это то, что основная задача программного кода - прятать сложность. Если вы оставите автора вашей любимой программы с необходимостью самому нормализовать unicode и сделать субпиксельный рендеринг с хинтами, то он просто плюнет и сделает вам обычную lookup-таблицу пререндереных символов, aka, растровый шрифт. И только на том подмножестве языков, которые знает (т.е. минус арабский/иврит, минус корейский и т.д.).
Современные компьютерные системы невообразимо сложны. Для того, чтобы человек имел возможность делать что-то осмысленное, ему нужна упрощённая модель, поддерживаемая кодом. Именно отсюда возникает а) огромная блобища, потому что абстракция, которая нужна программисту написана программистом с использованием абстракций слоем ниже б) невероятная скорость создания и возможности современного софта.
Быстрый пример: вы считаете совершенно нормальным, что вы копируете картинку с одного места в другое. Вы хотя бы примерно представляете себе какая это сложная задача? Потому что картинка может быть растром, может быть svg, может быть в одном из 100500 общеупотребимых форматов или быть в другом color space, не говоря уже о том, что понятие "картинки" может радикально различаться между программами во внутреннем представлении. А ведь оно почти в любом софте работает "из коробки". Но вы это принимаете как granted, и человек, написавший программу, тоже принимает как granted, хотя ему нужно лишние 10-20 строчек для правильной поддержки copy-paste написать. Всё остальное - слоем ниже. И ещё слоем ниже. И ещё. И так до самого низа, где низкоуровневый код операционной системы общается с ПО в оборудовании, написанном с помощью фреймворка и работающем в своей ОС.
Спасибо за развернутый ответ. Но опять согласен отчасти:) 20 лет назад тоже рендерили юникод строки. За это время изменилось разрешение экрана, но и мощности подросли на порядки. Область вывода скакнула с 800-600 до 4k. Хорошо я согласен, что пр таком разрешении пользователь видит больше текста и объектов. Но ведь не 100500 раз, больше:) Тормозить будет, если фигачить юникод строки, 60 раз в секунду без кеширвания и т.д Пример браузер, много текста и объектов, но даже на моем текущем пк athlon x4 640, большинство сайтов работает шустро. Ноутбуке с ryzen 5 по ощущениям раза в два в серфинг быстрее.
Копировали картинки и сложные объекты и 20 лет назад. Зависит от размера и сложности объекта.
Всегда держим в голове, что производительность выросла на порядки. Этого для растеризации шрифтов недостаточно? Сколько нужно? 10гц, для плавного хинтинга?
Программа и вправду может тормозить, вот только современный софт потребляет в среднем как видеокомбайн или аналог 3dMax 2005 года. Думаю, вы и сами сталкивались с таким софтом.
Пример. Открыл каталог system32 и перемещаю ползунок верх и вниз по каталогу, не очень то и быстро перемещаю. Загрузка ЦП 23%, Double Commander при прокрутке выедает 1 ядро на 100% Доколе:)
Проверю на ноуте с ryzen 5, и отпишу. Вдруг современный проц, сможет вывести настолько ресурсоемкую операцию:)
Забавная история в ту же копилку. Был у меня смартфон самсунг 2017 года. Его мощщи стало не хватать, чтобы в скайпе открыть список смайликов, выбрать один и послать. Зависон на 40с был.
Со временем я купил самсунг 2021 года. Не из-за скайпа, само собой. Теперь скайп стал работать сказочно быстро. Но после последнего обновления на той же операции снова висямба на 10с.
Мне прям дико любопытен стек вызовов на операции "показать список смайликов". Почему тот же телеграм их без всяких проблем мгновенно выдает?
Похоже, что он лезет на сервер, скачивает смайлики, загружает в приложение и после этого вы можете выбрать смайлик. И так каждый раз:)
Меня телеграм радует своей производительностью. У меня чатов 50, обычно 100-200 мб. Бывают всплески при звонке. Но тормоза не наблюдал. Только если задержки в сети.
да, со звонками в тг действительно бывают проблемы, особенно через мобильную сеть помехи и лаги нередки. Как ни странно, лучше всего для звонков у меня работает вк. Мало того, что связь там очень стабильная даже при слабом соединении, он еще и шумы при звонке подавляет очень хорошо.
Качество звонков из моего опыта, как не странно лучшее в Discord, особенно проклятое шумоподавление Krisp. Боже, ехать на самокатах и общаться, не слушая ветер 90% времени это что-то внеземное.
Не в обиду, но зачем вообще нужен скайп в 2022? Меня как фрилансера иногда прям раздражают общения в скайпе, ватсапе и прочем, когда есть куча приложений куда более быстрых и простых в использовании.
Последний заказчик (из США) тоже просил зарегаться в ватсапе, но я предложил ему попробовать телеграм просто, и с тех пор так и общаемся там, и он подтвердил что телеграм действительно удобнее.
Я еще могу понять ватсап/вайбер, но камон, какой скайп в 22? Зачем?
Есть дофига фирм, в которых скайп до сих пор используется как корпоративный мессенджер. То есть тупо предустановлен на всех компах фирмы. А телегу установить наоборот низя, потому что стороннее приложение, на согласование уйдет полгода.
Все очень просто. Родители в годах.
Какой мессенджер позволяет зарегистрироваться без номера мобильного телефона?
Затем, что не всем нужны шашечки. Если мне надо совершить видеозвонок, то мне совершенно без разницы в какой программе его делать. Для меня главное это качественная связь и чтобы программой умел пользоваться собеседник. А будет это скайп, зум, телеграм дело десятое. Все современные мессенджеры похожи друг на друга и отличаются какими-то незначительными нюансами.
Юникод в 2000ом году и в 2022 - совершенно разные вещи. Цветные эмодзи с кодами цвета кожи чего стоят, например.
Насчёт перехода с 1280 на 4k. 1280x1024 (реальное разрешение старого ноута, не самое плохое, кстати) - это 1.3Mpx. 4k - это 9.8 Mpx. Разница в 7.5 раз.
Процессор тех лет существенно медленее современного райзена, но не в сотни раз (нотубук о котором я говорю - это уже Intel Core, так что разница как раз примерно эти 7.5 и получается).
На другой машине я делал апгрейд как раз с Core 2 Quad (4 ядра 2.5GHz), на AMD Ryzen 5 5600X (6 ядер, 3.4GHz), на невероятно репрезентативной задаче (зато вычислительной и своей), и у меня между ними разница (в один поток) получилась "Запись в QuadTree с использованием f64 — улучшение в 2 раза. Поиск по дереву стал быстрее в 4.6 раза." (цитата). Получается, что разрешение вырасло в 7.5 раза, а скорость, дай бог, в 5 раз.
Добавил ваши и мои пк. Производительность на 1 ядро. Добавил проц 2003 года, athlon 64 3000+.
За 10 лет производительность выросла конечно, не в 10 раз. Но если сравнивать с компами с 2000+ года, то в десятки раз. И там таки был юникод:)
Вот, кстати, выглядит как брехня. Потому что у меня вставка в QuadTree (binary tree на плостности с 4мя квадрантами) стала быстрее всего в 2 раза. Я понимаю, что f64 - это вам не видео декодировать и всё серьёзно, но всё равно. По вашим бенчмаркам почти 10-кратное улучшение, по моим (в рамках вычислительно-графовой задачи) - от 2 до 5 (per core).
Общую производительность я бы не брал в расчет. Смотрите производительность на ядро.
Нормально выглядит. Просто в одном случае сравнивается производительность одиночной операции в одном вычислительном блоке, а в другом - полная производительность всех вычислительных блоков.
У двух процессоров может быть одинаковая производительность по операциям, например одна частота и одна скорость выполнения в тактах, но при этом совершенно разная производительность: один имеет один alu, а другой десятки, и ещё всякие avx-расширения, так что способен через себя за тоже время пропускать огромные потоки.
Бенчмарки естественно сравнивают полную противоположность - именно то, что будет использовать оптимизированный прикладной софт. А одиночная линейная операция покажет совершенно другие цифры - всё таки процессоры растут больше вширь, а не вглубь, поэтому оптимизации под железо сейчас так важны - нужно нагружать все исполнительные блоки железа по-максимуму чтобы код был действительно быстрый.
Для своих задач сравниваю производительность в архиваторах, и рост за десятилетие там тоже впечатляет.
Вот например мои тесты:
WinRAR
Armv7 Neon (2012) 2c/2t 1GHz 300kb/s
Intel HT (2005) 1c/2t 3GHz 300kb/s
Amd APU (2012) 2c/4t 4GHz 3000kb/s
Amd Ryzen 7 (2020) 8c/16t 5GHz 32000kb/s (3300kb/s single thread)
Все первые тесты в многопотоке были. Рост за 15 лет впечатляет, 2 порядка.
Половина современного ядра по вычислительной мощности превосходит совокупно все ядра прошлых поколений, работающие вместе.
Если вы рендерите шрифты на весь экран, то в общем случае у вас нет никаких средств акселерации. Да, у вас есть "быстрый bitblt", но с учётом что форма символа зависит от положения символа в строке (т.к. кернинг мы уважаем теперь, да?) то рендерить его приходится снова и снова. Есть кеш, который частично нагрузку снимает, но рисование на экране ttf шрифтами по правилам (т.е. правильным кернингом и сабпиксельным рендерингом) - это чистая задача на CPU.
Хотя спор опять куда-то в производительность ползёт, а речь про количество кода, на самом деле.
Шрифты рисуются на современных цпу. Я приводил пример браузера. Это не сверх задача, подсчитать размеры кернинг, сгладить и вывести на экран. К примеру я просто, колесиком перемещаюсь по данной статье в браузере, нагрузка на 1 ядро 100% и это нормально, браузер рисует шрифты, что то кеширует, перемещается по DOM дереву и т.д И кстати тормозов нет на ЦП 2010 года, процу 12 лет он вывозит эти ваши кернинги, ttf и сглаживание:)
Компоновка - конечно. А вот как на GPU рисовать TTF - я бы хотел почитать. Или вы просто махнули рукой, мол, там всё умеют и вроде на GPU? Я вот одну статью нашёл, но там ни слова про хинтинг. А это, простите, код для виртуальной машины, который надо исполнять.
Я бы посмотрел, как рисуют шрифты Chrome и WebRender от Мозиллы, это вроде как более прогрессивный движок с ориентированием на отрисовку как можно большего на GPU
Пример. Открыл каталог system32 и перемещаю ползунок верх и вниз по каталогу, не очень то и быстро перемещаю. Загрузка ЦП 23%, Double Commander при прокрутке выедает 1 ядро на 100% Доколе:)В Проводнике могут быть расширения Проводника, установленные сторонним ПО. И они почти никогда не написаны идеально. Нужно сравнивать на чистой системе.
Вы реально мой тезис игнорируете. Вам очень хочется, чтобы я говорил про то, что программам надо много делать и они заняты рендерингом тяжёлых вещей.
А я говорю, что программистам, которые делают так, чтобы программы много делали, нужно иметь ограниченную по сложности задачу. Потому что если любому человеку попросить вот это вот отрендерить с нуля (вот тебе API ядра для bitblt и запрос для определения текущего разрешения и области вывода), то это будет нерешаемая за разумные сроки задача.
Значит, человек берёт готовый код. Не потому что он ленивая жопа которой лень пошевелиться ради быстрой программы, а потому что срок реализации программы без всех этих фреймворков (построенных на фреймворках, и так до самого дна, которое в свою очередь ABI между одним процессором и программой на другом процессоре) превысит срок жизни человека.
Другими словами, есть проблемы с фрейворками, с их оптимальной реализацией? Это уже ближе.
Нет, это не проблемы. Проблемы с ожиданием поведения от софта. От каждой утилиты мы ожидаем правильной обработки всего юникода. Unix-подход (байтстринг на вход, байтстринг на выход) уже не катит.
От каждого редактора сообщений ожидают эмодзи, картинок и ещё чёрта в ступе. От каждого приложения - работу во всех мыслимых и немыслимых разрешениях и DPI, понимание 100500 форматов, часовых поясов, локалей, направлений ввода текста, и правильную обработку обрезания арабского текста.
Соответственно, каждая программа это должна уметь. Единственный метод "уметь" - использовать библиотеки/фреймворки, которые эту нагрузку на себя ведут.
Грубо говоря, у вас такой жирный и медленный редактор, потому что он в любой момент в рантайме готов вам показать правильно свёрстаную корейскую надпись посредине статьи на идише. И это не вопрос "обрезайте при компиляции". Этот функционал ожидают от софта, и он должен быть на месте. Вместе с эмоди, для того, чтобы склеить иконку "третьего тона кожи" с "двумя детьми" и "одним взрослым" и правильно посчитать кернинг для получившегося.
Это мы ещё не затронули несколько сетевых протоколов с простынями алгоритмов шифрования, подсветку синтаксиса 100500 языков и т.д.
И всё это ожидается, что есть и работает. Это очень много кода, который пассивно ждёт своего момента.
Можно, но кто-то должен написать оптимизированный common case. А неоптимизированный уже есть, бери пользуйся.
А он есть. Вы прямо сейчас им и пользуетесь, и он работает.
Какой-то мудрец догадался туда avx2 засунуть, но не догадался что ввод-вывод дороже будет чем сам подсчёт. Да и не у всех этот avx2 есть, гнать таких мудрецов надо, чтобы не мусорили. Зачем мне в памяти держать код работы с avx, sse, 100500 драйверов на устройства, которых у меня нет? Кто-нибудь об этом подумал? И ещё, я 100% не буду себе на комп ставить программы, за разработку которых мне платят деньги. Не потому что я плохо что-то делаю, а потому что над программой ещё десяток криворуких мудрецов поиздевались.
Мне по коду всё ясно, это вам нужно собирать. Кеш процессора, построенный на sram памяти, будет всегда быстрее чего угодно. Длина avx инструкций будет больше коротких процессорных, для задачи подсчёта количества оно точно не надо, там кроме сумматора ничего не надо.
У вас мусор в голове. Только начали знакомиться с вычислительной техникой?
(: Могу, там avx видимо для здоровых чисел нужен, поскольку uintmax_t lines, words, chars, bytes. Так что да, пусть будет. Но я так и не понял почему 64 бита не хватает. И вдруг 256 не хватит, тогда что, avx уже маловат, код в мусорку, и всё по новой. Скорости он там точно никакой не даёт, fread банальный урежет её. Просто кто-то поленился писать на асме сложение для длинных чисел, а оно там элементарное.
Ну вот вы и попали в ловушку маркетологов. Теперь кроме intel и amd ничего на всей планете нет :). Не, avx там только для жирных чисел нужен, сам сперва подумал что кто-то чего-то ускоряет, но таки нет, видимо кому-то нужно интернет в байтах, словах и линиях мерять.
Не, avx там только для жирных чисел нужен, сам сперва подумал что кто-то чего-то ускоряет.
Интересно, а смотрел ли мьсе исходники чтобы так безапелляционно что-то утверждать?
github.com/coreutils/coreutils/blob/master/src/wc_avx2.c
Я думаю, что как человек, который уже ознакомился с вычислительной техникой, вы сможете найти там внутренний цикл.
Есть близкий пример, который большей частью опровергает ваш тезис:
Человек в свободное время без особых амбиций написал терминал с поддержкой рендеринга любого текста (большей частью моноширинного, но с поддержкой эмодзи, арабского и пр.), чтобы показать, насколько Windows Terminal жирный и медленный. Причём он рендерит текст лучше, чем Windows Terminal. И да, он рисует на GPU.
обрезания арабского текста
У них даже текст обрезается?!
А какую часть из этого вы ходите оптимизировать? Выкинуть постгрес? Докер? Переписать клиента на нативном API для каждой ОС? Переписать код на питоне в код на (you-favorite-here)?
Просто хочу добавить, что на программиста давят экономические соображения (сделать быстрее == прибыль), но при этом эти экономические соображения тянут с пользователя.
Пока всё работает, проблем нет. Проблемы начинаются, когда глючный код перестаёт работать, или когда программе пора работать, но программист ещё упражняется с ассемблером. Это полный провал! В итоге все предпочитают условный питон, который работает раз в 25 раз медленнее, чем следовало бы, но позволяет кодить левой пяткой и всё равно в 5 раз быстрее и надёжнее.
Разница только в том, что пользователь -- не разработчик и не специалист, он не знает как могло бы всё работать и поэтому проглатывает эти косты молча.
Уж лучше пусть не знает, чем знает наполовину или на 5%. Как правило, частичное знание приводит к мечтам о бесконечной оптимизации, но ничего не говорит ни о затратах на оптимизацию, ни о корректных методах оптимизации. Когда-то я пытался объяснять таким продвинутым пользователям механизмы работы виртуальной памяти, но для не-программистов это слишком подробное погружение в тему. Увы, чтобы понять подобные вещи, нужно потратить примерно несколько семестров на соответствующей специальности или прочитать несколько толстых книг. Пользователям есть чем заняться кроме этого, они могут быть специалистами вообще в другой области.
Практически все задачи на компьютере должны выполняться за <0.1с
Не все задачи могут выполняться за 0.1с, т. к. не все задачи одинаковы. Сжатие видео тоже должно выполняться за 0.1с? А чтение произвольного объёма данных с диска?
должны выполняться за <0.1с (блин, да именно за это время гугл успевает пролистать индекс всего интернета, провести рекламный аукцион и ещё миллион дел и выдать результат)
пролистать индекс всего интернета
Гугл выполняет поиск на кластере из тысяч машин. Производительность у него совершенно другая, чем у домашнего компьютера. Вы не захотите иметь такой кластер дома, он большой, дорогой, требует дорогого обслуживания и т. д.
Идея индексирования как раз в том, чтобы не просматривать весь индекс. У меня от выделенной в цитате фразы возникают подозрения, что вы недостаточно хорошо понимаете, как работает поиск, map reduce, параллельное программирование вообще, раз приводите сильно распараллеленную задачу в противопоставление коду на десктопе, где ядер-то не больше десятка, а задействуется чаще всего одно ядро. Это противопоставление некорректно.
Естественно, хорошо параллелизуемая задача может выполняться за 0.1с на кластере из тысяч компьютеров, поддерживаемом штатом инженеров, с отдельной электростанцией, соответствующей системой охлаждения и т.п. Но если ваша задача - например, считать данные с диска, чтобы запустить программу, то объём, что вы успеете вытянуть за 0.1с с одного типичного ssd - всего 20-50МБ. Хорошо, если программа занимает 20МБ, ведь её ещё нужно слинковать с библиотеками и инициализировать... А если бинарник вместе с библиотеками мегабайт на 400, они только считываться будут секунду, и обойти это сложно.
400 мегабайт — это больше размера целой операционной системы, такой
как Windows 2000 — весь этот код точно нужен для того, чтобы показать
начальное окошко?
Объем такого порядка занимает одна лишь библиотека Cuda для операций над матрицами... И что теперь, матрицы не на gpu перемножать? Win 2000, к слову, решает другую задачу.
почему это не помогает запускать программы мгновенно?
Найдётся какая-нибудь ещё инициализация, которая займёт время.
Сама идея, что для запуска программы нужно прочитать полгигабайта — не кажется вам сомнительной?
Таки кажется, но это от сложности программы зависит.
А сколько в библиотеке Cuda на 400 мб, собственно этих самых мб относятся непосредственно реально к функционалу библиотеки? Может там примеры, документация и т.д
И если перемножение матриц занимает 400 мб so или dll, что там может занимать столько места?
Это dll имеют размер такого порядка (точно размер я не помнил, посмотрел сейчас: старые библиотеки cudnn - 270МБ, cufft - 128МБ, cublas - 50МБ - всё же меньше, чем 400). А место в них, по-видимому, занимает gpu-код, который скомпилирован под ~десяток архитектур GPU, да ещё и с инлайнами всех вызываемых процедур, да ещё и на С++ подобных шаблонах. Зато работает быстро и почти на всех GPU.
Сразу вспомнилось:) Если заменить ошибку, на тормозной код.
А сколько он сэкономил человеколет своей программой?
Наверное Джон настолько плохой программист, что пишет только ошибки
А почему тогда 10 миллионов человек используют "только ошибки" которые пишет Джон? Как же так получилось, что пользователь номер 9999999 видя как страдали пользователи до него и как он страдает (а почему страдает, если в коде только ошибки? Оно же просто не работает) посоветовал программу пользователю номер 10000000.
Не складывается шутка, не складывается.
Иронично, но ваш комментарий приложен в виде картинки объёмом более 400 КиБ, а весь текст - примерно 2 КиБ в UTF-8. И почему браузеры/компьютеры/программы стали так медленно работать?
Картинку вывести ПК вообще на изи.:) И нет браузеры/компьютеры/программы тормозят не иза моей картинки на 400кб:) Инфа 146%
а теперь вот открытые в просмотрщике картинок ваша и моя картинка. угадайте, в каком окне ваша, а в каком моя, если учесть, что сама программа без открытых картинок потребляет 2 метра оперативки.
если вам кажется, что всё это ерунда полная, то на самом деле проблема состоит не из-за этой голимой картинки, а в общем и целом из маленьких мелочей, которые в итоге оптом вырастают в огромную картинку.
вы же сами жалуетесь своим постом, где В софте все всрато и становится еще всратее и сами же пренебрегаете довольно очевидными вещами, деля на ноль эту самую статью.
если бы мракософт хоть немножко задумывался о том, что он делает и как в плане оптимизации, то вангую, что последняя венда могла бы весить, например, раз в 15 меньше, то бишь мегабайт 300-350 вместо 5 гигов. а если конкретно так психанула бы, то и вовсе в ~100 мегабайт уложилась. но это сложно, да, там программировать надо, а не мышкой по красивым кнопочкам тыкать.
производители игрушек на таких мелочах зарабатывают миллиарды долларов, используя систему микротранзакций. пользователи с удовольствием относят им туда свои бабки. им кажется, что 15 центов ерунда, но 15 раз по 15 центов это $2.25. за эти деньги можно неплохо пообедать дома, ну или купить шавуху. а если играть каждый день в такую игрушку, в месяц это почти 5 тыщ рублей. а жизнь состоит не только из одной игрушки. таких микроплатежей море и в реальном мире.
таким образом можно понять, сколько своего и чужого пространства, энергии и времени расходуется непонятно как, лишь бы ничего не делать. но эта лень в итоге приводит к тому, что нужно покупать всё более мощные железки, которые оправдывали бы свою предыдущую лень, чтобы продолжать лениться и дальше.
пока каждый думает, что от его всратой говнистости ему пофиг на окружающих, то он забывает, что с таким поведением все остальные думают точно также и бумеранг возвращается не один.
вот создал один программист одно всратое приложение и этим приложением пользуются все. даже этот же самый программист. а если он не хочет пользоваться своим говноподелием, то для него есть сюрприз — он не одинок в этом мире. программист из соседней конторы тоже создал какое-то говноподелие, которое внезапно нужно первому программисту. вот так оба программиста нахаляву говна поели, как в том анекдоте, а создатель инструмента для всратого программирования повысил свою рентабельность на рынке как владелец той самой стодолларовой купюры (банк), укрепивший свою валюту. но программистов миллионы, а главный герой один и пользуется он явно не одним приложением, а десятками, и все они одинаковы с лица, и все они говно. и вот ему приходится страдать и бежать покупать очередное новое железо, потому что старое уже не вывозит всего этого дерьма. а деньги зарабатывают на самом деле не программисты, а корпорации, на которые они работают. говнокодеры и прочие генераторы говна сами же помогают производителям делать ещё более мощное железо для своей ещё более мощной будущей лени, причём абсолютно бесплатно.
чем больше говна генерируется, тем больше на вас заработают. и мракософт всё это говно всецело поощряет. нужно больше всратого говна богу всратого говна.
не ожидал, конечно, что родится такой поток сознания, но с возможностью комментирования раз в сутки — и так сойдёт.
Винду не удастся ужать до 300Мб - основное её преимущество бинарная совместимость, соответственно им приходиться внимательно хранить большую часть багов и недокументированных фич - так как есть софт который их использует и это ещё не худший вариант.
Читал про багу с определением високосного года: уже давным-давно нет того офисного пакета, где была бага и даже ОСи где он запускался, но мс офис делался с полной совместимостью к тому пакету, поэтому бага до сих пор присутствует там и во всех другом софте который хочет быть с ним совместим
Или про HMM3 - по легенде на старых версиях wine он работал лучше (стабильнее) чем на винде, но по мере допиливания и соответственно увеличения списка софта, который wine поддерживает HMM3 стал вылетать так, же как и в виндах
Про размер винды я согласен: уже чистая семёрка весила раза в 3 больше, чем мой линух со всем необходимым софтом...
Причём даже не смотря на свой размер, там нет библиотек, которые наверняка потребуются, например от Visual Studio
Урезанием винды я тоже увлекался, потом ещё сделать образ и в случае проблем за несколько минут получаем чистую винду
Я думаю, большая часть содержимого винды кому-то (может быть единицам) нужно, убрать дубли тяжело, т.к. они лишь частичные
Предустановленный софт и компоненты - да, хорошо бы без, но они на это не пойдут
зато есть версии винды без них
И правда, цитировать следовало не картинкой, а перепечатав текст, чтобы сэкономить драгоценные байты и такты. Цитата картинкой противоречит вашим тезисам. И, осознав это, вы начнёте понимать программистов, которые пишут неоптимальный код.
Такое себе сравнение. Софт потребляющий сверх своих возможностей, это констатация факта. Картинка в 400 КБ, почти ничего не стоит пользователям в сравнении, даже в общей скорости и затратам по цп при загрузке данной статьи с комментариями.
Вы сами использовали 400КБ, чтобы кодировать 500 символов - это 800 байт на символ (!), и утверждаете, что программисты используют компьютер недостаточно эффективно. Если бы вы перепечатали вручную текст, вы бы их поняли чуть лучше. Но на самом деле всем плевать, 400 байт там, 400КБ или 400МБ, пока система выполняет свои функции.
Да, именно так. Потому что для того, чтобы не вводить адрес вручную, нужно иметь систему загрузчика, который в свою очередь должен поддерживать миллион разных опций, и для этого есть ВООТ ТАКЕННЫЙ фрейворк (я плохо телефонные потрохи знаю, но для мира PC это UEFI). И этот фреймворк запускает другой фреймворк, который вам и dual partition для загрузки, и шифрование, и дисковое кеширование, и всё остальное.
Вы не поняли моей иронии. Если вы кто-то не написал 100500 кода для поддержки suspend/resume, то каждый раз, когда вы тыкаете кнопку на телефоне, вам бы надо было бы вводить адрес загрузчика. Потому что телефон бы загружался как какой-нибудь мейнфрейм. Для которого процесс загрузки - это метод упростить жизнь программистам, которым больше не надо кодировать реальные адреса для переходов вручную в ассемблере под конкретную модель. (да-да, первый в мире загрузчик назывался initial orders и занимался именно этим - релоцировал программу и расставлял в ней адреса переходов).
Сейчас именно так и происходит. Ставим Windows + Docker + redis и уже гб 2 ушло.
В линуксе примерно такая же картина. Не спорю контейнеры очень удобны, всякие flatpack и иже с ним. Но ведь они тянут с собой все зависимости. И большой вопрос в том, что разработчики просто не озаботились вкомпилить в бинарник только используемый код. Пару функций из Qt Core, еще нескоько виджетов из QtGui, а загружается весь фреймворк. То же самое и с GTK. И если программа написана не на С++, без возможности статической линковки, это сделать невозможно. Будут загружены все библиотеки.
Ремарка. Будут загружен весь фреймворк, но для всех приложений его использующих.
И большой вопрос в том, что разработчики просто не озаботились вкомпилить в бинарник только используемый код
А имеют ли разработки такое право? А готовы ли они принять последствия?
Плюс быстрых фреймворков в том, что из юзают миллионы людей в виде конечного софта. То есть экономим ресурсы на миллионах устройств. Но так как устройства и так очень быстрые, в чем выгода для компаний тратить ресурсы на такие глупости. Проект работает, а фигли надо:) Выкатили премии получили. Короче замкнутый круг.
На свежих квалкомах например тот-же UEFI и даже тот же смый EDK2...
uboot он такой, да, пока подумает, пока попробует, и FPGA образы тоже небыстро, а потом еще и линукс, и всё каждый раз заново в RO разделы.
А там еще и баги есть, и в самом загрузчике, и в загружаемых образах.
А пользователь хочет, чтобы телефон стартовал всегда, даже, когда завис и получил hard-reset, вытащили батарейку и т.п., а не подключать UART или распаивать JTAG, когда игрушка за штуку баксов окирпичится из-за «непредвиденной последовальности действий» или космической частицы, или когда где-то i2c подвиснет чуть дольше, чем допустимо.
Вот там вам и резервные разделы, и хитрый апдейт.
А ещё подписывание, шифрование, противостояние взлому. В бутерброде из множества супервизоров/ОС, которые работают одна поверх другой.
В «примитивном» смартфоне для лайканья сисек и фотканья котиков.
Вот тут мы подходим к ещё одному фактору, зря сжирающему ресурсы — т.н. «безопасности». Вся эта секьюрная лабуда вечно тормозит, глючит и куда больше вредит самому пользователю, чем потенциальному злоумышленнику.
Контейнеризация, виртуалки, эмуляция, полная изоляция работающих программ друг от друга и постоянная проверка прав доступа — это всё очень дорого стоит в плане ресурсов. Создание «песочниц» изначально дорогущая операция. А ведь во времена MS-DOS машины как-то работали и без всего этого. Даже защищённого режима в процессорах — и того не было.
П.С.: одна из самых прожорливых программ на ноуте любого пользователя — это антивирусник с эвристиками и активной защитой, навешанной на каждый вызов API любой программы. После его удаления скорость работы системы обычно возрастает в разы.
Я верно понимаю, что вы предлагаете пользователю иметь два телефона – один для соцсетей и лайканья, а второй, где озаботились безопасностью, под банковское приложение?
А ведь во времена MS-DOS машины как-то работали и без всего этого
Если мы вдруг откатим эти технологии вспять, вы осознаёте, какое раздолье появится для вирусов, развивавшихся годами? Вы готовы прямо сейчас опубликовать все ваши личные пароли в открытый доступ? Ибо такова цена
Это ведь сарказм, да?
А пользователю точно-точно нужно подписывание, шифрование и противостояние взлому в смартфоне для лайканья сисек?
Если в смартфоне бывают банковские данные - точно нужно.
Создание «песочниц» изначально дорогущая операция. А ведь во времена MS-DOS машины как-то работали и без всего этого
Работали, но как-то не очень. Скорее даже "дико глючили", чем "работали".
Контейнеризация, виртуалки, эмуляция, полная изоляция работающих программ друг от друга и постоянная проверка прав доступа — это всё очень дорого стоит в плане ресурсов.
Контейнеризация практически ничего не стоит, это просто трансляция файловых путей, сетевых имён, портов и т.д. для отдельных процессов, выполняемых на том же ядре ОС. Изоляция программ, к счастью, поддерживается процессором на аппаратном уровне.
Контейнеризация, виртуалки, эмуляция, полная изоляция работающих программ друг от друга и постоянная проверка прав доступа — это всё очень дорого стоит в плане ресурсов. Создание «песочниц» изначально дорогущая операция. А ведь во времена MS-DOS машины как-то работали и без всего этого. Даже защищённого режима в процессорах — и того не было.
И на ровном месте были BSOD'ы в той же Win95. После установки изврат-методами(потому что 12 Mb RAM) NT4 — BSOD'ы пропали на тех же задачах а быстродействие не упало (Ну только что с играми возникли сложности)
Между вводом адреса загрузки в восьмеричном формате и кучей неотпимального говнокода на python есть огромная пропасть. Uboot - далеко не главный пожиратель ресурсов.
Да, конечно. Но альтернативой неоптимальному говнокоду на питоне будет оптимальная программа на... Только не говорите про раст, пожалуйста. Такого прожирателя места ещё поискать (а всё потому что кому-то лениво писать код без generic'ов). Видимо, на ассемблере? С годом сдачи заказа ... time.ctime((2**31))?
В зависимости от задачи и требований: оптимальный говнокод на питоне, на JS (все еще быстрее питона), на Lua, на C#, Java, Go, C++, на C, на Haskell ну и на Rust, в конце концов.
а всё потому что кому-то лениво писать код без generic'ов
Разве при мономорфизации объем кода не будет такой же, как если бы мы "нелениво" раскрыли все дженерики руками копипастой?
Только не говорите сколько СО2 это стоит миру :)
***Краткая история оптимизация программы на Python***
Ускоряли как-то Python
Cython скомпилили в "сишку"
Вызвали из "сишки" - "сишку"
"Сишка", "сишка", "сишка", "сишка".
Показательно, но автор как-то рано остановился - не задействовал видеокарту.
Как минимум можно было:
1) Выкинуть STL и писать на C-массивах;
2) Попробовать развернуть циклы обработки массива и постараться оптимизировать проверки с помощью ассемблера;
3) Таки-да, задействовать всю мощь параллельной обработки данных на видеокарте;
4) Возможность стоило подумать про отдельное аппаратное решение данной проблемы на FPGA;
5) Следующим способом ускорить алгоритм является переход к решению на ASIC-ах, надо только написать оптимальную структуру с учетом разработок на FPGA.
Для компиляции вселенной, какие ключи юзать при сборке?:)
1) Выкинуть STL и писать на C-массивах;
Ужасный код, замедлит выполнение
2) Попробовать развернуть циклы обработки массива и постараться оптимизировать проверки с помощью ассемблера;
Ужасный код, замедлит выполнение, лучше компилятора вы не сделаете, нет кроссплатформенности
3) Таки-да, задействовать всю мощь параллельной обработки данных на видеокарте;
Ужасный код, куча зависимостей, нет кроссплатформенности, производительность упадёт, т.к. функция часто вызывается с маленьким объемом данных(уверен, что в статье создаются треды каждый раз вместо использования тредпула и это уже половину времени занимает)
4) Возможность стоило подумать про отдельное аппаратное решение данной проблемы на FPGA;
Не имеет смысла
Компьютеры реально быстры и мы этого реально не знаем.
Бывает тебе показывают экранную форму с данными и она грузится 2 секунды, ты такой "а почему я должен ждать 2 секунды?", а тебе отвечают типа, "там показывается много полей, они должны быть прочитаны из базы и размещены в представление, надо развернуть много экранных элементов и заполнить их в тяжелом фреймворке...", а ты такой "люди, что же вы делаете, компьютер же может выполнить миллиард гребаных операций за секунду, ну почему ему нужно 2 миллиарда операций, чтобы показать несчастные 30 полей с данными?", а тебе так, это фреймворки, это технологии, ты просто не понимаешь...
а что делает сам компьютер в это время? простаивает или выполняет бессмысленные для конкретной задачи вычисления?
а что делает сам компьютер в это время? простаивает или выполняет бессмысленные для конкретной задачи вычисления?
Если бы кто знал!
Я представляю себе это примерно так. Допустим, мы можем нарисовать на экране элементы просто через некую базовую графическую библиотеку. Но это неудобно, поэтому кто-то пишет библиотеку, которая позволяет создать объекты-графические примитивы с множеством сложных функций и нарисовать элементы с помощью этих классов. Это медленнее чем исходный вариант раз в 10, но это все еще очень быстро и никого не волнует. Дальше, эти элементы будут не просто рисовать себя библиотекой. Они будут еще описывать как себя рисовать каким нибудь xml который надо парсить. Потом поверх этого напишут библиотеку со всякими анимациями и байндингом, потом кто-то возьмет библиотеку с этими элементами и поверх напишет свою новую супер библиотеку с гораздо большими функциями и опциями в разных версиях, в разных вариантах.
Получается очень сложное здание из множества слоев, каждый из которых тормозит работу в n раз. N умножается на n и снова на n, получается медленно, но все еще не плохо. А потом из за сложности кто-то где-то забывает написать какую-то функцию оптимально. В итоге все начинает тормозить неимоверно, но прогресс пошел уже дальше, никто не хочет копаться в кишках, все хотят еще больше возможностей, еще больше слоев.
В итоге мы имеем на компе довольно примитивные мессенджеры которые падают как будто это виндовс 95 и жрут как будто это целая IDE. Но зато все обеспечены работой, очень сложной и требующей высочайшей квалификации.
Это нормально. Печально только когда программисты забывают насколько на самом деле быстро работает компьютер и начинают искренне верить, что диалог в принципе никак не может выскочить без ощутимого лага, если в нем "много" элементов.
Но это моя теория.
А опенсорс, где каждая библиотека выполняет одну конкретную функцию - это панацея, если любой сможет оптимизировать любую библиотеку и она сразу при следующей компиляции любого проекта где она используется будет браться из репозиториев и перекомпиляции?
Это ладно, а представьте сколько всего такого в бюрократической машине
Имхо, дело в большом кол-ве слоёв абстракций: невозможно написать оптимальный код не зная контекста, а знать его нельзя т.к. не угадаешь кому, что, как и когда потребуется. Причём не только сейчас, а в ближайшие пару-тройку десятилетий.
Оптимизировать можно, но есть большой шанс, что в одном месте заработает быстрее, а в другом замедлиться. Или к моменту завершения оптимизации код фичи будет выкинут )
Согласен - программист должен понимать, почему медленно и исходя из этого решать оставить так или переписывать
с одной стороны С\С++ отличный - на нем код разных нативных функций работает быстро,
а с другой стороны (смотрит как печально компилируется большой ынтерпрайз С++ проект с нуля), мне чистый питон тоже нравится
Ну это чисто С++ маразмы. На Паскале например всё быстро компилируется и скорость работы не сильно хуже.
Не соглашусь. Компилятор gcc это миллионы строк кода, где 80% процентов это оптимизация, эвристики и т.д
Думаю, что сильно хуже будет.
Мне Паскаль нравится, на нем первый p код реализовали. И сам язык более целостный.
Ну с Free Pascal да, в 3 раза различие - https://habr.com/ru/post/563078/ .Но даже PascalABC по производительности его побеждает - http://pascalabc.net/stati-po-pascalabc-net/28-meryaem-proizvoditelnost
Но при этом на ABC лучший результат был в статье 0.45 с , а на Delphi я получал 0,25с. Так что низкая производительность Pascal в тестах часто связанна с конкретной реализацией.
Он хотя бы на компиляции ошибки находит, а питон просто сломается по дороге
ошибки компиляции все компиляторы находят.
Ошибки рантайма С++ тоже только в рантайме обнаружит.
к чему этот снобизм ?
Что это вообще значит? Вы поняли что сказали?
Все ошибки, которые находит компилятор языка Х во время компиляции непосредственно вытекают из правил языка Х иначе это какой-то бред
На плюсах можно много чего выразить, даже очень много.
Запрет глобального состояния (ввод вывод это тоже глобальное состояние)- объявите функцию constexpr
Можете ещё noexcept поставить, говоря что она точно не аллоцирует и не фейлится
В С++ такая свобода создания своих абстракций, что вы можете написать себе сколь угодно сложную логику проверки чего-либо на компиляции.
Используйте библиотеки, которые уже написаны и проверяют свои инварианты. Например стандартная библиотека.
Пока это всё на уровне "ну я пишу плохой код, значит С++ не даёт возможности писать хороший".
Почему же вы тогда не пишете про то, как упадёт эффективность разработчика, если его форсить писать всё "доказуемо на компиляции"(при том что большинство эффективного кода тогда просто будет невозможно)
Утверждаю, что это возможно. Только количество работы, которое вам придётся проделать будет велико.
И конечно же вы всегда можете ошибиться на уровне доказательства, так что ваша ошибка компиляции ничего не будет говорить, либо вовсе будет ложной. И так будет на любом даже теоретическом языке программирования.
А теперь представьте какого писать на языке, на котором вам придётся это ВСЕГДА описывать. Не даром такие языки не пользуются популярностью - на них просто хрен что напишешь
он это проделывал 1000 раз ("Давайте измерим. насколько быстро работает эта функция при 1000 вызовах"(С) ), но в целом - я с вами солидарен
Я что-то ни черта не понял. Что там было в тех непоказанных функциях sort_by_time и sort_by_score, что 1000 сортировок фрейма на 10 строчек занимает ВОСЕМЬ, МАТЬ ЕГО, СЕКУНД?
Есть смутное ощущение, что ускорение в первом пункте было достигнуто не переходом с пандас на питоновские списки (это даже звучит абсурдно), а разгребанием авгиевых конюшен в тех "закулисных" функциях.
Спасибо!
Тема также раскрыта в https://youtu.be/1nx3YXq6gG4
Научно технический-рэп, Папа может в Си
Если сделать вывод. То программисты под влиянием бизнеса, а бизнес под условиями рыночка, всрали всю производительность, софт и фреймворки могут быстро работать, но в текущих условиях это невыгодно, а значит не нужно. Пара-пара-пам,:)
как только "продукт продается" - то дальше оптимизировать невыгодно.
Вот реально - оптимизировали мы игровой движок в два раза, тут же набежали дизайнеры и вкрячили в два раза больше объектов в сцену.
Итого ФПС вписался в бюджет ? - все, значит следующий раунд оптимизации и рефакторинга "отложен до лучших времен" ...
но в текущих условиях это невыгодноДаже не то, чтобы не выгодно, а практически вредно. Пока вы годами вылизываете производительность, конкурент уже выпустил продукт, продаёт его и разрабатывает следующее поколение продукта. К тому времени, когда ваш продукт выйдет на рынок, он уже будет безнадёжно опоздавшим. Оптимизированным, но никому не нужным, а на вас показывают пальцем «смотрите, они смогли догнать фирму А спустя 5 лет».
Добавил статью в закладки, и буду кидать ее коллегам, кто скажет может попробуем питон. Не для всякой аналитики, а прям в прод.
Очень сильно от типа задач зависит. Во многих случаях можно и Питон в прод, легко.
И вспоминается мне EVE Online. Где и сервер и клиент внезапно написаны на питоне.
Правда там рендер там совсем не на питоне и питон не обычный а Stackless и куча хитрых оптимизаций(которые CCP не особо и скрывали) чтобы работало нормально а если начинает тормозить — чтобы тормозило для всех одинаково.
Плохой не Python и Pandas, плохой был первичный код, который в оригинале статьи - отсутствует. Статья понравилась. Она на самом деле повествует о том что несколько сомнительных преобразований сделали зачем-то в Pandas, причем обернули их во вложенные функции, вызов которых в Python и мн. других динамических языках - дорог. Писали, например, датасатанисты, которые в Pandas делают все, даже файловые операции. Видимо это работало, приносило прибыль. Но прод затребовал realtime. Дальше классика. Оптимизировал программист, наивно, без Pandas, на чистом Python и получил... внезапный прирост в ~100 раз. Ничего удивительного что плохой код можно улучшить многократно, просто переписав его "на месте", тем же языком, только правильно.
А вот все дальнейшие оптимизации были стандартны и предсказуемы. Они дали ускорение с 12 сек. до 0,2 сек. (в 60 раз), что хорошо подтверждается другими подобными статьями и кейсами. Но там никакого чуда нет - вынос тяжелых функций в C/Numba/Nuitka итд хорошо известен. Да, однопоточный Python медленнее статических многопоточных языков в ~60 раз, это всем хорошо известно и питонистами не оспаривается. Потому что в 98% задач это замедление незаметно никак. А если вспомнить что на Питоне пишется в в 100 раз быстрее - то рост его популярности становится не таким уж парадоксальным.
Вывод: не стоит никого отговаривать данной статьей. Одни программисты ошибаются - другие исправляют, третьи пишут статьи с процентами ускорения вместо более понятных кратностей, видимо, для пущей важности. В промилле было бы еще быстрее.
Есть еще один ньюанс. Код на С должен выполняться не в 2 и не в 10 а сотни раз быстрее аналогичного кода на питоне. Но возникают проблемы c преобразованием типов из питона и обратно. К примеру небольшие функции смысла портировать нет. расходы на конвертацию съедят все.
Да, уж, убили Паскаль. Потом опять создали простой язык - Питон, но который в 100 раз медленее. Вот так "прогресс" и идёт.
Не читал кучу комментариев выше, но мне одному странно, что в реализации на С++ функция объявлена как double agg_efficient(), а возвращает вектор?
Ну и вообще, если вся реализация теперь на С++, то каким боком тут внешняя обёртка из Питона?
Комментарии к статье, не менее интересны, чем статья.
Я тут разрабатываю в свободное время небольшую либу, как реализую базовый функционал надо будет написать на хабре статью.(Пока даже управление потоками нет)
https://github.com/JordanCpp/Lt
В ней и реализую разные концепции, возможность использовать аллокаторы, статическую линковку, pimpl на уровне заголовочных файлов и т.д
И у меня есть такая помойка https://github.com/Alexey1994/Engine
Помойка только потому что ни мне ни кому-либо из моих знакомых оно не надо. Писал потому что мог и хотел.
Прекрасно. Выбросьте pytuhon и напишите всё то же самое на lua.
Библиотека Pandas языка Python отлично подходит для экспериментов с данными, но ужасна в продакшене. Если оказалось, что вы используете её в продакшене, то настало время повзрослеть.
Если вы используете питон в продакшне, то пора повзрослеть.
В статье не рассмотрен ещё вариант с ХОРОШИМ кодом на С++
Будьте осторожнее, за отрицание использования питона в проде минусуют:)
А какая разница? Длина члена от этого не уменьшится. Сколько тут не пишу всегда минусуют. Вот вам конкретно для чего плюсы нужны? Я вот сишку без всяких плюсов использую, потребности в плюсах не испытываю, а если надо чего подинамичнее, то lua подключаю. И на хабре плюсы бесполезны, ибо плюсуют мусор в основном. Да и во всём интернете так: то что заплюсовано банальный шлак. А норм инфу массовый потребитель не понимает, ему пропаганду подавай, там где всё разжёвано и все вопросы отвечены.
Я с вами согласен. В своем сообщении я специально, поставил смайлик в конце, дабы понять, что это саркастическое предложение.
У меня другой опыт. Писал недо движок для простой 2d игры и скрипты планировал писать на c++, как и движок. Для простоты, не городить плагины в виде so и dll, а собирать в единый исполняемый файл. Плюсы меньше зависимостей, ну и по фану.
на самом деле - самые большие тормоза в современных программах не изза алгоритмов, а изза избыточного копирования (+ маршаллинг\демаршаллинг)
Был недавно опыт, использовал библиотечный обьект, который удобный но "жирноватый". На вложеном цикле в двадцать на триста тысяч оборотов этот "жир" вылился в неприемлимое время ожидания ответа. Заменил на самописную минимальную имплементацию - все ускорилось почти в сто раз.
Я так понял, что создание объектов видимо стоит больше производительности чем можно наивно предположить. И чем крупнее структура объекта тем больше производительности требуется на его создание. Может в какой-нибудь яве это не так сильно сказывается, но вот на питоне я это почувстовал.
Статья о том, что pandas, скорее всего, не очень подходит для массированной обработки большого количества массивов по 10 чисел )))
А теперь напишите функции на С для обработки больших массивов данных с нетривиальными индексами и реальными операциями на них. Я посмотрю, сколько лет вам на это потребуется )))
И да, значительная часть функциональности уже реализована под капотом на С…
algorithm_wizardry?
я что то не понимаю тут один?
Компьютеры быстры, но вы этого не знаете