И что мы видим?
1) Переписыванию подверглись два вспомогательных сервиса
2) "most of our backend logic lives in Django"
3) Обогнать динамический Питон — не велика заслуга
4) Переписывали наверное не тупо строка в строку, а, все таки, фикся все известные косяки. И какой тут вклад от фикса косяков, а какой от С++ — очень большой вопрос. Я вон рядом приводил пример, когда удалось ускорить на пару порядков и снизить траты на сервера в 1.5 раза, оставаясь в рамках дотнета.
И далее мы видим что таки основное это был переход с синхронного на асинхронное IO. Не знаю что там у Django, но в C#/JVM с этим никаких проблем нет.
Еще лет 10-15 назад попадались вакансии программистов фортран, для поддержки каких-то старых банковских систем с зарплатами значительно выше среднего по рынку. Думаю, что со временем С++ будет ждать такая же участь, но в отличии от фортрана наследие куда больше. Отдельным особняком будет стоять С, OS, гипервизоры (хотя firecracker написали на Rust-e), движки СУБД и прочий "хард-рок" явно так и будет поддерживаться и развиваться.
Но в целом, что бы начинать новый продукт на С++, нужно иметь веские основания. Оставаться на С++ безусловно можно и скорее всего это будет даже очень денежно, новые проекты будут сужаться, но поддержки и развитие старых на наш век точно хватить, а вот количество спецов С++ будет неуклонно снижаться.
А разве утверждалось, что был переписан весь Instagram? Речь изначально шла только о "части":
Поэтому Instagram переписывает часть своей инфраструктуры с Python на C++ и сокращает количество серверов с 700 до 40.
Кроме того, пример с Instagram был приведен в качестве иллюстрации вот этого предположения:
Теперь мейнстрим -- это Java, C#, Go, Python, Ruby и иже с ними. Скорость разработки у всех приблизительно одинаковая, зато стоимость владения теперь сильно определяется ресурсоемкостью приложений. И, оказывается, что Python и Ruby, да и Java, местами, сильно проигрывают какому-нибудь Go. Не говоря уже про C++ или Rust.
И там же была вторая иллюстрация, связанная с переписыванием с Python на Go:
А Dropbox переходит с Python на Go (и, местами, на Rust).
Так что не понятно, с чем вы собрались спорить. Нигде не утверждалось, что ту же самую переделку в Instagram нельзя было сделать чем-то другом. Просто переделка была сделана с Python на C++.
DI>>из самого факта переписывания части инфраструктуры Instagram-а с Python на C++
S>Там все именно про это. А в заключении английским по белому написано: S>
We were able to increase the peak CPU utilization of the Suggested User service from 10–15% to 90% per instance. This enabled us to reduce the number of instances of the Suggested Users service from 720 to 38.
И при чем тут Питон?
S>>>Мне сложно понять, как "сделать что-нибудь на плюсах" не означает, что "на плюсах пишут". Но у вас какое-то свое представление о логике.
DI>>Ты пишешь на плюсах, плюсы компилируются в ассемблер.
S>Во-первых, нет.
Конечно да, надо знать свой инструмент. Запусти g++ с ключом и -v и удивись, что сначала cc1plus создает .s файл, а его уже as транслирует в объектник.
DI>>Сначала тезис 700 против 40 надо доказать.
S>Научитесь работать с источниками.
Здравствуйте, so5team, Вы писали:
S>А разве утверждалось, что был переписан весь Instagram?
Это ж было написано в пику утверждению, что С++ становится нишевым.
S>Кроме того, пример с Instagram был приведен в качестве иллюстрации вот этого предположения:
Негодная иллюстрация вышла.
S>
Теперь мейнстрим -- это Java, C#, Go, Python, Ruby и иже с ними. Скорость разработки у всех приблизительно одинаковая, зато стоимость владения теперь сильно определяется ресурсоемкостью приложений. И, оказывается, что Python и Ruby, да и Java, местами, сильно проигрывают какому-нибудь Go.
Только твой пример проигрыша, как оказалось, не демонстрирует, а других примеров никто не привел.
S>И там же была вторая иллюстрация, связанная с переписыванием с Python на Go:
S>[q]А Dropbox переходит с Python на Go (и, местами, на Rust).
И при чем тут С++?
S>Так что не понятно, с чем вы собрались спорить. Нигде не утверждалось, что ту же самую переделку в Instagram нельзя было сделать чем-то другом. Просто переделка была сделана с Python на C++.
Здравствуйте, lpd, Вы писали:
lpd>Я не фанатик С++ — хотите чтобы это был нишевой язык для быстрых вычислений — ваше дело. lpd>Просто я не люблю JVM с байт кодом, и думаю что для всякого бэкенда обычный язык вроде C++98+GC(или D) подошел бы лучше.
На нишу быстрых вычислений пока никто не претендует.
D выглядел очень симпатично, но не взлетает.
SVZ>>Я уже ранее писал, что проблема возникает из-за передачи владения объектом. Ограничь владение объектом, задай графу связей направленность и проблема уходит.
lpd>Ограничь владение объектом что значит и задать графу связей направленность — не то же самое, что убрать круговые ссылки? Вместо [A->B;B->A] только [A->B]?
[A->B;B->A] можно оставить.
Определяем иерархию — есть родительский объект, есть дочерние. Родительский объект отвечает за время жизни дочерних.
"Умер папа, умерли и дети".
Это позволяет сделать weak ссылки между объектами в иерархии.
Удаление выполняется из одной точки. Чтобы не было висящих указателей добавляем некий "суперкласс", который знает про всю иерархию. Перед удалением пройдет по объектам, расцепит связи.
Но надо задачу смотреть. Может получиться дорого, а может и нет.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>А разве утверждалось, что был переписан весь Instagram?
НС>Это ж было написано в пику утверждению, что С++ становится нишевым.
Во-первых, не говорилось про то, что был переписан весь Instagram, речь шла про часть инфраструктуры. Часть была переписана? Была. Еще вопросы?
Во-вторых, про "написано в пику" -- это ваша интерпретация. Неверная. Поэтому оставлю вас спорить с вашей же интерпретацией.
НС>Негодная иллюстрация вышла.
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Здравствуйте, lpd, Вы писали:
SVZ>[A->B;B->A] можно оставить. SVZ>Определяем иерархию — есть родительский объект, есть дочерние. Родительский объект отвечает за время жизни дочерних. SVZ>"Умер папа, умерли и дети". SVZ>Это позволяет сделать weak ссылки между объектами в иерархии.
Например у меня в сервере деление на родительские и дочерние объекты было не всегда(для сессий соединения, пользователей). Особенно если у многих из родительских есть ссылки на несколько дочерних, общих с другими родительскими, и время жизни разное. Так что такая схема не во всех случаях хорошо подходит. Точнее, счетчик ссылок(c shared/weak указателями) в таком случае это один из вариантов, и не самый плохой, но GC бы справился лучше и проще.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>Во-вторых, про "написано в пику" -- это ваша интерпретация. Неверная.
НС>Верную в студию.
С середины 1990-х где-то до 2010-2012-го был вполне себе понятный тренд -- на фоне быстрого роста мощности компьютеров все большее и большее распространение стали получать языки с более высокими накладными расходами, нежели у нативных языков, но зато дающими более высокую скорость разработки и большую безопасность. Поэтому Java, а затем C# стали вытеснять C++ и Delphi. Уже в 2000-х динамические языки, вроде Python, Ruby и Perl стали все шире и шире использоваться для разработки объемного софта.
Но вот где-то с 2012-го регулярно стали появляться новости о переписывании чего-нибудь опять на C++. А чуть позже и о широком использовании Go вместо Python-а или Ruby. Плюс к тому добавились разговоры о высоких расходах на содержание больших парков серверов. Т.е. если раньше было "мы запросто можем отмаштабироваться на 1000 серверов", то потом стало "хорошо бы обойтись 100-ней серверов вместо 1000".
Поэтому у меня лично есть открытый вопрос на который я сам пока не имею четкого ответа: а не происходит ли разворот мейнстрима? Что нативные языки без GC начинают рассматриваться как возможность получить конкурентное преимущество и/или значительно снизить стоимость эксплуатации?
Здравствуйте, checkthestack, Вы писали:
C>Посоветуйте — пора валить из плюсов в какой-нибудь go? Или можно найти на плюсах нормальную работу, если у тебя не 6+ лет опыта в нём?
В JS и на бэкэнд со всякими кубернетисами, докерами и прочими прыщами, либо уходить в сервер-сайд на С++/Go. Неплохо бы изучить Пистон.
Здравствуйте, lpd, Вы писали:
lpd>Например у меня в сервере деление на родительские и дочерние объекты было не всегда(для сессий соединения, пользователей). Особенно если у многих из родительских есть ссылки на несколько дочерних, общих с другими родительскими, и время жизни разное. Так что такая схема не во всех случаях хорошо подходит. Точнее, счетчик ссылок(c shared/weak указателями) в таком случае это один из вариантов, и не самый плохой, но GC бы справился лучше и проще.
Ну в таком случае надо смотреть, а не поможет ли введение внешнего "суперкласса", который будет выполнять удаление и распутывание связей между объектами.
Тогда удаление будет выполняться из единой точки, всегда в определенном порядке и проблема циклических зависимостей опять уходит.
Дисклеймер.
Я не агитирую, просто рассказываю, как решались проблемы в проектах, в которых я работал.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Ну в таком случае надо смотреть, а не поможет ли введение внешнего "суперкласса", который будет выполнять удаление и распутывание связей между объектами. SVZ>Тогда удаление будет выполняться из единой точки, всегда в определенном порядке и проблема циклических зависимостей опять уходит.
Получается что-то вроде GC, только работающего на основе логики иерархии классов приложения, а не указателей. Тоже решение, но почему бы не использовать встроенный GC? Если только из-за скорости. Но и GC можно отключить при необходимости.
И GC и умные указатели(в некоторых специальных случаях) имеют право на жизнь, как и описанный тобой вариант. Но вот в C++ добавили только shared/weak/unique_ptr<>. Причем теперь вроде как фанатично агитируют делать все до одного указатели умными, что неудобней GC, да и громоздко выглядит в коде.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, so5team, Вы писали:
S>Поэтому у меня лично есть открытый вопрос на который я сам пока не имею четкого ответа: а не происходит ли разворот мейнстрима? Что нативные языки без GC начинают рассматриваться как возможность получить конкурентное преимущество и/или значительно снизить стоимость эксплуатации?
Вот тут я не понял, в какой момент ты от Питона с Руби перешел сразу к языкам без GC, тем более что в Go GC есть, да еще и довольно примитивный. И что демонстрирует твой пример, в котором основной плюс в перфомансе дал переход на non-blocking API, а не отказ от GC?
Здравствуйте, CreatorCray, Вы писали:
CC>Нудным голосом напомню что язык это всего лишь один из инструментов, и что валить надо в то, за что платят — предметную область. Язык же будет зависеть от этой самой предметной области.
Ну смотри, в штатах все большие компании нанимают так называемых Generalist и какой там язык?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Вот тут я не понял, в какой момент ты от Питона с Руби перешел сразу к языкам без GC, тем более что в Go GC есть, да еще и довольно примитивный.
Давайте попробуем, но если и в этот раз будет не понятно, то оставим все как есть, значит не судьба.
Итак, вначале никого не парило, нативный или код исполняется или нет. Затем это стало важно и случился переход с Python/Ruby на go (местами и с Java на go). Но это может быть лишь промежуточный шаг, поскольку дальше производительность/ресурсоемкость можно улучшить за счет отказа от GC (т.к. GC при всех своих достоинствах все-таки накладывает ограничения и имеет свою стоимость). Поэтому после перехода на нативные языки с GC может последовать и переход на нативные языки без GC. Или сразу на них, чтобы не тратить деньги/время дважды.
Показательно, что Dropbox при переписывании с Python на Go, не смог обойтись без нативного языка без GC, в их случае это был Rust.
НС>И что демонстрирует твой пример, в котором основной плюс в перфомансе дал переход на non-blocking API, а не отказ от GC?
Вообще-то это ваша интерпретация рассказа разработчиков из Instagram. Подозреваю, что неправильная. Перечитайте внимательно первоисточник.
А демонстрирует он как раз то, что можно сразу из Python в С++, минуя промежуточные стадии и полумеры.
Здравствуйте, kaa.python, Вы писали:
S>>Об этом факте сами разрабы писали: https://instagram-engineering.com/c-futures-at-instagram-9628ff634f49 S>>Остальное было разбросано по интернету в обсуждениях на разных ресурсах.
KP>А взяли бы Go и получили на выходе тот же результат, но в 2-3 раза быстрее
Статья написана в 2015-ом, возможно, происходило все это в 2014-ом. Не факт, что Instagram в то время качество Go устраивало.
Здравствуйте, so5team, Вы писали:
S>т.к. GC при всех своих достоинствах все-таки накладывает ограничения и имеет свою стоимость)
Вот только конктерно в C# есть возможность писать unsafe код. Практике же показывает, что участков, критичных к оверхеду GC в реальных проектах крайне мало, и переписывать весь проект на С++ не нужно, даже если экономия на GC критична.
S>Поэтому после перехода на нативные языки с GC может последовать и переход на нативные языки без GC.
А может и не последовать. Тем более что особо активного перехода на нативные языки с JVM/CLR пока тоже не видно.
S>Или сразу на них, чтобы не тратить деньги/время дважды.
НС>>И что демонстрирует твой пример, в котором основной плюс в перфомансе дал переход на non-blocking API, а не отказ от GC? S>Вообще-то это ваша интерпретация рассказа разработчиков из Instagram.
Это не моя интерпретация, это прямо следует из написанного. Во-первых большая часть статьи посвяжена как раз этому, во-вторых малая загрузка процессоров (на основе которой и посчитана экономия) прямо свидетельствует, что упирается все не в процессор (как было бы, если бы затык был в неэффективном коде интерпретатора или работе GC), а в блокировки.
S> Подозреваю, что неправильная. Перечитайте внимательно первоисточник.
Верну твой совет тебе. Если не согласен — попробуй объяснить с чем связана низкая загрузка процессора в оригинальном решении, и почему переход на С++ оптимальный вариант борьбы с этим.
S>А демонстрирует он как раз то, что можно сразу из Python в С++
А что, кто то в этом сомневался? С дуру можно и МПХ сломать. Вопрос в том — нужно ли это.
