Pull to refresh

Comments 33

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

Там в английской статье, на которую стоит ссылка, показано, что grep работает в 50 раз быстрее.

работает быстрее по сравнению с чем?

Note that grep and wc don’t actually solve the word counting problem, they’re just here for comparison.

Чтоб сосчитать слова, в подавляющем большинстве случаев достаточно одного прохода по тексту, что и делают grep и wc. И пары массивов – например, счётчик частот, индексируемый 16- или 24-разрядным самым тупым хешем, и ссылки на сами слова (или их позиции в файле, если не хотим читать файл целиком). Только для разрешения коллизий хеша придётся делать второй проход.

Я недавно реально подофигел, что grep работает даже быстрее индекса в mysql
Тоесть на моих данных выгоднее выгрузить спискок в файл и пройти grep, чем искать с использованием индекса в памяти.
grep реально быстро работает.
Думаю потому, что индексы оптимизированы для совпадения слева. А вы скорее всего ищете слова в центре и тогда индекс превращается в просто сокращенную версию таблицы, которую СУБД и перебирает — что, конечно, лучше перебора исходной полной таблицы, но сильно хуже поиска по двоичному дереву. Grep, подозреваю, выигрывает потому, что читает данные бОльшими порциями относительно mysql.
Неа, слева, от 3 до 8 символов, только цифры. Таблица в 30млн.

Смотря какой Индекс Вы имели в виду

последовательное считывание файла с диска выполняется очень быстро

Поверхностное гугление показывает, что производительность чтения из кэша процессора составляет порядка терабайта/с, производительность чтения из RAM порядка 40ГБ/с. Т.е. диск всё ещё на 3 порядка отстаёт от кэша примерно как и в старые добрые времена, и на полтора от RAM.

Ниже показаны усреднённые результаты трёх лучших прогонов в секундах:

Сразу вопросы к эксперименту: у дисков есть свои кэши, последовательные прогоны в поисках лучшего наверняка осядут в этих кэшах и результаты будут уже не те, как по первому разу. Также наверно и в RAM после первого эксперимента прочитанное с диска частично тоже где-то закэшируется.

Диски-то тоже разные. Конечно, у большинства сейчас SSD в новейших макбуках. Но HDD тоже встречаются пока еще. А еще сетевые диски бывают. Например, в AWS облаке GP2 диски вообще хз что из себя представляют - там вполне может быть файл размазан по нескольким сетевым дискам и кроме вас еще 200 серверов с ними сейчас работают и время доступа будет непредсказуемым и нелинейным.

Позвольте уточнить - современные м.2 ssd способны читать последовательные данные со скоростью 7 Гб/секунду. ОС, файловая система и т.п. могут накладывать оверхед, но я предлагаю отталкиваться именно от теоретической верхней границы, как и для 40 Гб/сек для оперативной памяти.

Мне кажется, на старых компьютерах с жёсткими дисками соотношение скоростей было совсем не таким.

Переход от жёстких дисков к ssd m.2 выглядит действительно прорывом - раньше по sata нельзя было передавать больше 550 Мегабайт в секунду (на практике диски достигали 100-150 мегабайт в секунду при последовательном чтении), а рандомное чтение вызывало задержки, измеряемые в миллисекундах.

Сравнить 150 мегабайт/сек старого жёсткого диска и 7 гигабайт нового ссд - разница полтора порядка.

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

Ну вы и сравнили - старую практику и современный теоретический потолок

Ну, из "ввод/вывод" в статье рассмотрен только ввод. Да и, в общем-то, мизерного объёма данных)

Что касаемо основного вопроса («Что является узким местом производительности вашей программы?), то единственный правильный ответ тут: без бенчмарков разговор бессмысленен :)

Очень спортное утверждение, все еще не подтвержденное ничем.
С точки зрения быстродействия процессора и чтение из случайного места ОП - медленное так то. И есть методики (типа ESC или векторизации), которые наглядно демонстрируют, насколько.
Поэтому то, насколько быстрее стали диски, все еще не опровергает утверждение, что I/O медленное.

Первое апреля? Правда смешно! Особенно когда увидел что это в хабах "Совершенный код" и "Клиентская оптимизация"

Хорошо бы еще помнить, что помимо throughput есть и latency. И совершенно различные паттерны доступа.

UFO just landed and posted this here

На одной работе было такое приложение. Есть хранилище с несколькими миллиардами документов, надо их проиндексировать. Надо получить порцию данных (20000 документов), декодировать JSON, взять поле, декодировать Base64, декодировать JSON еще раз, взять список полей, сгенерировать XML, вывести в STDOUT, который читает индексатор. Обработка на PHP. Сеть работала быстро, вывод в STDOUT тоже, тормозил PHP. Сделали много параллельных процессов по числу ядер на сервере со сбором данных в главном процессе и запуск с небольшой задержкой, чтобы не все сразу лезли в сеть. Тогда стало упираться в работу индексатора.


Когда много данных и работы со строками, сеть перестает быть узким местом.

413Мб - это даже близко не BigData. Начали бы хотя бы с 413Гб - да и слов уникальных бы побольше (для теста можно брать не слова из текста а парные сочетания всех слов друг с другом, ну и книжек заодно не одну взять а 1000). А так вообще-то боле менее серьёзный уровень BigData обозначился бы на 413Тб или 413Пб - но это в "домашних" условиях уже моделировать очень сложно. Но и 413Гб началась бы уже совсем другая кухня - где текст так просто в память целиком не загнать. А с большим количеством слов (или как я предложил - парных словосочетаний из 1000 книг - ну или программно сгенерированный источник с миллиардами таких вот "сочетаний") началась бы ещё и проблема с хранением статистического массива. Да BigData - это не шутки, там совсем другие законы и подходы. Но, у Вас в компании видимо совсем не уровень BigData раз это всё для Вас не важно.

И как можно говорить об оптимизации и BigData, когда нет параллельной обработки (тем более то на Go) - а там сразу ещё и задачи конкуренции возникают (что тоже на собеседовании проверять неплохо бы).

Да и если говорить о файле (даже если он один - что даже интереснее, но в BigData такое бывает редко) очень большого объёма - то даже его чтение можно было бы немного распараллелить - раз ввод-вывод занимает почти на порядок меньше времени чем обработка!

И всё надо асинхронизировать!

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

Как говорится, +1

Более того, для сетевого ввода это тоже может быть верно.

Пример – чтение таблицы целиком из PostgreSQL (SELECT * FROM <TABLE>) в Perl при помощи fetchall_arrayref. Если просто читать данные, то память под массив с результатом выделяется один раз, и чтение занимает примерно Х времени. А если попытаться эти данные обрабатывать, передавая полученный массив аргументом в какую-нибудь функцию, то уже 5×Х

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

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

Не все же системные программисты, и не все даже знакомы с с Си и C++. Да и под разными средами исполнения память выделяется по-разному. "Управляемые приложения", в т.ч. скриптовые вообще создавались так, чтобы программисты меньше задумывались над этим вопросом. Хотя, вот C# - например не так уж прост вопросах выделения памяти (чем, скажем Java), особенно с версии NET CORE 3 - но там своя кухня и нюансы. И не надо говорить - что люди разрабатывающие приложения на высокоуровневых ЯП - не программисты, раз не углубляются в особенности памяти. Они да - не системные, а прикладные программисты. И современные ЯП развиваются так, чтобы разработка приложений на них шла так, чтобы больше думать о прикладной логике, чем о низкоуровневых заморочках. И даже BigData идёт путём к тому, чтобы меньше думать о нюансах той или иной низкоуровневой прослойки платформы, и больше об оптимизации логики обработки больших массивов. Мне трудно представить каким была бы разработка сайтов или прикладных приложений баз данных, если бы программистам приходилось думать о тонкостях выделения памяти

Ну, я впервые узнал, что передача значения может быть копированием либо по ссылке, будучи чистым питон-программистом. Просто потому, что эти темы всё равно всплывают, когда начинаешь разбираться, почему код работает так как он работает — даже если это высокоуровневый язык.
А потом смотришь какие запросы orm делает к бд, потому что
1. Программист не заморачиваться
2. Orm тупенький

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

ORM просто пока ещё тупенький - но это пройдёт со временем. Ну а тупые программисты были, есть и будут всегда.

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

Но это всё пройдёт!

ORM просто пока ещё тупенький — но это пройдёт со временем.

главное в это сильно верить, питоновскому django 17 лет, если его бездумно юзать он память и транзакции в базу жрет капец
сколько еще времени ждать, еще лет 17?

Джанго, вроде, не ORM а на все руки мастер в каждой дырке затычка.
Как насчет Ecto?

в каждой дырке затычка.

и в ней есть ORM которые все повально юзают в питонячих проектах где джанга есть
а тащат еще много куда изза DRF

Как насчет Ecto?

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

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


UPD: с остальным согласен, но администрирование БД выходит за рамки работы программиста, а значит и его инструментов… включая orm.

Предвидеть всё не возможно никому! Но есть вещи, которые ИИ может делать и делать лучше людей:

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

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

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

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

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

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

ну вот я могу тоже сказать 'вот в будущем, ИИ будет делать всё, ну сейчас просто еще уровень не тот, но вот как только так сразу'
да, тут согласен, когдато так будет
но я побоялся бы даже прогнозы делать в среднесрочной перспективе. лет 5-10, потому что 10-15 лет назад слышал точно такоеже разговоры буквально слово в слово, что вот уже вотвот и всё… аа… и где? копилот который бездумно ворованныетиповые куски кода подставляет?
где ОРМ который заменит программиста который знает чуть больше чем insert-select и как правильно БД создать чтобы мучительнно больно не было данные из неё доставать?

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

И по сути - это никакой не ИИ - а просто продвинутый информационный аналитический алгоритм с кодогенератор! Поэтому - никакой фантастики - одна математика!

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

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

Не 17 а 117!

Не ждите - пишите на асме свою идеальную СУБД- 100% будет быстрее - но писать будет явно дольше 117 лет!

Sign up to leave a comment.

Articles