выделение лишних трёх байтов даже на машинах с адресным пространством в 64 Кбайта (в т.ч. PDP-11, где, по сути, и появился Уних вместе с Це) -- отнюдь не гигантский перерасход памяти
Идеология C закладывалась на PDP-7, где в базовом варианте было всего 4К слов. Но речь даже не об этом. Популярность C приобрел потому, что подходил не только для весьма мощных для того времени PDP-11, но так же и для микропроцессоров и микроконтроллеров.
Для понимания, первый ZX Spectrum имел всего 16К RAM, из которых почти половина была занята под видеобуфер. Atari 800 имела только 8К. МК 8048 имел всего 128 байт RAM, а до сих пор встречающийся 8051 - 256 байт.
Даже сейчас на маломощных МК можно встретить эти же 128 или 256 байт оперативной памяти. Наапример, в МК Padauk.
Так что будьте снисходительны к Ричи. Тогда действительно каждый байт считали. И сейчас на некоторых МК тоже приходится это делать.
Это совершенно штатное использование шуруповерта. Я своей древней Макитой 6891D, которая еще на NiCd АКБ, без проблем метров 80 забора из профнастила на три лаги прикрутил.
полагаю что под сериализацией/десериализацией XML подразумевалось
После такого, я уже точно не вижу смысла в продолжнии дискуссии. Почитайте, хотя бы в тут. Любой RPC вызов - это сериализация объектов на одной стороне и десериализация на другой.
Остальное даже комментировать не буду, так как не вижу понимания того, что такое конвейер, протокол, контракт, их версии и для чего они нужны.
Там просто парсер XML-запроса и генерация ответа в виде строки.
Первое - и есть десериализация. Второе - сериализация. А то что примеры в публикации не содержат в запросах и ответах ни массивов, ни массивов структур - это уже точно не ко мне.
сомневаюсь что причина лишь в одном только протоколе
Сомневаться - дело хорошее. Плохо, когда человек при этом ничего не делает. Хотя найти подтверждения моих слов очень легко. Например в этой публикации в тестах получили разницу в 7-10 раз, что вполне согласуется с моими данными. Код там есть, так что можете проверить сами.
Вы бы тогда скорее снижением объема трафика хвастались - размеры передаваемых данных по бинарному протоколу разумеется заметно меньше.
Во-первых, объем траффика тут тоже играет роль, так как если внутри ЦОД может быть до 400 гигабит на паре двухпортовых адаптеров, то между клиентом и сервером gRPC часто будет десятигигабитка, а порой даже гигабитка. Во-вторых, объем данных - это еще нагрузка на TLS, сериализацию и десериализацию. В-третьих, сам по себе HTTP/2 существенно эффективней HTTP/1.1. Тем более при использовании двунаправленного потокового gRPC и пакетной конвеерной обработки. А у нас запросы в Protobuf на несколько мегабайт с ответами на гигабайт - вполне себе обычны. В REST это было на порядок больше, так как в основном там массивы чисел. В XML-RPC было бы еще в 2-3 раза больше из-за его многословности в массивах.
То что вы «нагуглили» это разумеется замечательно, но это не истина в первой инстанции.
Так как большинство ссылок на github, истинность проверяется элементарно. А ссылки на сайты производителей коммерческих продуктов, вполне себе валидные по определению.
По этой причине могу подтвердить что оно действительно работает на момент написания статьи.
На платформах, не поддерживающих Java, вроде упомянутого выше ESP32?
Я просил пример, где, по Вашему мнению, gRPC не применим. Вы же выдали целый ворох групп. Вы действительно ожидали, что для каждой из систем, покрываемых этими общими группами, я приведу работающий код?
не хочу скатывания разумной технической дискуссии в очередной бессмысленный срач.
Простите, но уже скатились, предложив сериализацию и десериализацию XML на встраиваемых системах, где каждый байт оперативки на счету и CPU слабые. Надеюсь, понимаете, что gRPC требует на порядок меньше оперативной памяти и в разы меньше процессорных ресурсов, чем XML-RPC. Я знаю о чем говорю, так как когда мы переходили с REST на gRPC, то получили прирост производительности, в среднем, в 8-9 раз.
Разумеется там будет компилятор, но только устаревший, у которого проблемы компиляции даже не находятся поисковиками.
Кросскомпиляцию никто не отменял. А на K&R С, не говоря уже об упомянутых выше FORTRAN и COBOL, сериализацию и десериализацию XML сложнее будет реализовать, чем gRPC. Что я тоже показал выше.
Потому что архитектура 1С неспособна переваривать такие объемы данных. Например, в той же Тульской области порядка миллиона приборов учета. С каждого из них в среднем, считывается десяток-другой регистров каждые 15 минут. И не просто считываются, а анализируются, валидируются, агрегируются, сопоставляются с техническими приборами учета и т.п. А эти данные даже шардировать тяжело, из-за переключений и колец.
Мне приходилось общаться с 1С. Даже на таком небольшом предприятии, как ювелирный завод Ника, приходилось иметь десяток инсталляций со сложными схемами интеграции между ними и регулярными проблемами с консистентностью. Когда не только для готового изделия, но и для множества компонентов, заготовок и материалов надо учитывать содержание драгметаллов для каждой единицы отдельно, 1С очень сильно просаживается в производительности.
любой сектор, любая область, все что только поддается учету, все на 1С можно учитывать
Не утрируйте. Биллинг - тоже финансы. Но попробуйте на 1С поднять биллинг электроэнергии с АСКУЭ даже не для МосЭнергоСбыта, а хотя бы для Тульской или Ярословской областей.
Ключевое слово "сеньеров". То есть, специалист, который кроме php знает SQL, Redis, Kafka, ClickHouse, gRPC/Protobuf/Swagger, k8s, RabbitMQ, SSL/TLS, HTTP/2, Kerberos/Oauth/Openid и т.п. А даже хорошее знание только языка программирования - это лишь джун+.
Просто разработчик не всегда аналитик. И наоборот. Но с опытом это приходит.
Последняя "дичь" была у меня - требование прогнозировать временной ряд по среднему арифметическому. До сих пор добавляются фильтрации, валидации, ограничения периода и т.п. Не то что на NN или ARIMA, даже на медиану не были согласны, при этом признавая, что точность прогноза будет выше, а вероятность ошибки при учете сезонности - ниже. Как выяснилось, всё потому, что зам. директора хочет иметь возможность самостоятельно проверять прогнозы, а ни о каких медианах и аримах он не знает и знать не хочет. Ну что, "любой каприз за деньги заказчика". )
Ну есть еще возраст. Меня под 60 стали куда-то звать намного реже, чем лет 10 назад. А самостоятельно работу я искал всего пару раз в далекой юности. Все остальные смены работы происходили по горизонтальным связям без всякого отсева и с фиктивными собеседованиями.
То есть, предлагается в течении нескольких месяцев, если не года изучать "java,Javascript,python,android,Linux,windows,opencv,ML,opticflow,SQL,qt/qml,rust,c/c++,с#,dsp,delphi", а за это еще и деньги платят? Для джуна, кое-как освоившего только C++, выглядит совсем неплохо )
Обратите внимание, что я изначально не указывал конкретные языки, а выше привел их лишь для примера. Я указал список, который позволит адаптироваться почти на любом проекте.
Так про то и речь, что только с Java по горизонтальным связям выбор будет в несколько раз меньше, чем если к Java добавить хотя бы C/C++ или Rust, Python или Perl, ну и SQL.
Например, на последнем месте, меня взяли на 80% C#, T-SQL и PL/pgsql, но при этом обязательно требовалось знание R и Python. А по ходу дела выяснилось, что необходимо еще дорабатывать sink для Kafka на Java, несколько OpenSource на C и, в качестве вишенки на торт, некоторое количество legacy на Perl. И именно по горизонтальным связям меня сюда и заманили, зная, что я со всем этим справлюсь.
А как же карта свободного пространства и карта видимости?
А они не нужны для вышеописанных трех сценариев выборки одной записи.
Поэтому оракл создает файл нужного размера сразу, чтоб фрагменированность была минимальной.
Я же указал выше, что фрагментированность всё равно будет. Причем сам Oracle даже не будет знать, где в файле заканчивается один экстент и начинается другой. И, тем более, ничего не знает о sunit и swidth, что весьма актуально уже для любого RAID, в том числе и на SSD.
С другой стороны ФС совершенно ничего не знает про данные - какой прирост данных будет в файле, с какой интенсивность.
СУБД тоже об этом мало знает. Обычно, только в рамках одной транзакции. Но и файловая система будет сбрасывать кеш на диск только после завершения транзакции и получения sync(), а лишь тогда аллоцировать место на диске под закешированные данные. При этом статистикой записи в каждый файл она тоже располагает, эвристически вычисляя allocsize в каждом случае.
Идеология C закладывалась на PDP-7, где в базовом варианте было всего 4К слов. Но речь даже не об этом. Популярность C приобрел потому, что подходил не только для весьма мощных для того времени PDP-11, но так же и для микропроцессоров и микроконтроллеров.
Для понимания, первый ZX Spectrum имел всего 16К RAM, из которых почти половина была занята под видеобуфер. Atari 800 имела только 8К. МК 8048 имел всего 128 байт RAM, а до сих пор встречающийся 8051 - 256 байт.
Даже сейчас на маломощных МК можно встретить эти же 128 или 256 байт оперативной памяти. Наапример, в МК Padauk.
Так что будьте снисходительны к Ричи. Тогда действительно каждый байт считали. И сейчас на некоторых МК тоже приходится это делать.
Это совершенно штатное использование шуруповерта. Я своей древней Макитой 6891D, которая еще на NiCd АКБ, без проблем метров 80 забора из профнастила на три лаги прикрутил.
После такого, я уже точно не вижу смысла в продолжнии дискуссии. Почитайте, хотя бы в тут. Любой RPC вызов - это сериализация объектов на одной стороне и десериализация на другой.
Остальное даже комментировать не буду, так как не вижу понимания того, что такое конвейер, протокол, контракт, их версии и для чего они нужны.
Первое - и есть десериализация. Второе - сериализация. А то что примеры в публикации не содержат в запросах и ответах ни массивов, ни массивов структур - это уже точно не ко мне.
Сомневаться - дело хорошее. Плохо, когда человек при этом ничего не делает. Хотя найти подтверждения моих слов очень легко. Например в этой публикации в тестах получили разницу в 7-10 раз, что вполне согласуется с моими данными. Код там есть, так что можете проверить сами.
Во-первых, объем траффика тут тоже играет роль, так как если внутри ЦОД может быть до 400 гигабит на паре двухпортовых адаптеров, то между клиентом и сервером gRPC часто будет десятигигабитка, а порой даже гигабитка. Во-вторых, объем данных - это еще нагрузка на TLS, сериализацию и десериализацию. В-третьих, сам по себе HTTP/2 существенно эффективней HTTP/1.1. Тем более при использовании двунаправленного потокового gRPC и пакетной конвеерной обработки. А у нас запросы в Protobuf на несколько мегабайт с ответами на гигабайт - вполне себе обычны. В REST это было на порядок больше, так как в основном там массивы чисел. В XML-RPC было бы еще в 2-3 раза больше из-за его многословности в массивах.
Так как большинство ссылок на github, истинность проверяется элементарно. А ссылки на сайты производителей коммерческих продуктов, вполне себе валидные по определению.
На платформах, не поддерживающих Java, вроде упомянутого выше ESP32?
Я просил пример, где, по Вашему мнению, gRPC не применим. Вы же выдали целый ворох групп. Вы действительно ожидали, что для каждой из систем, покрываемых этими общими группами, я приведу работающий код?
Простите, но уже скатились, предложив сериализацию и десериализацию XML на встраиваемых системах, где каждый байт оперативки на счету и CPU слабые. Надеюсь, понимаете, что gRPC требует на порядок меньше оперативной памяти и в разы меньше процессорных ресурсов, чем XML-RPC. Я знаю о чем говорю, так как когда мы переходили с REST на gRPC, то получили прирост производительности, в среднем, в 8-9 раз.
На этом предлагаю закончить.
Lisp, TCL, окружения Linux старше 15 лет, практически все коммерческие Unix, промавтоматика, встраиваемые системы
Сами погуглить не могли?
Кросскомпиляцию никто не отменял. А на K&R С, не говоря уже об упомянутых выше FORTRAN и COBOL, сериализацию и десериализацию XML сложнее будет реализовать, чем gRPC. Что я тоже показал выше.
Не понял, какие проблемы? Приведите хотя бы один пример, где невозможно заменить XML-RPC на gRPC.
Вы знаете платформу, для которой нет C/C++ компилятора или бекенда для LLVM?
В том же FORTRAN или COBOL куда проще реализовать вызов через gRPC, чем сериализацию и десериализацию XML.
Потому что архитектура 1С неспособна переваривать такие объемы данных. Например, в той же Тульской области порядка миллиона приборов учета. С каждого из них в среднем, считывается десяток-другой регистров каждые 15 минут. И не просто считываются, а анализируются, валидируются, агрегируются, сопоставляются с техническими приборами учета и т.п. А эти данные даже шардировать тяжело, из-за переключений и колец.
Мне приходилось общаться с 1С. Даже на таком небольшом предприятии, как ювелирный завод Ника, приходилось иметь десяток инсталляций со сложными схемами интеграции между ними и регулярными проблемами с консистентностью. Когда не только для готового изделия, но и для множества компонентов, заготовок и материалов надо учитывать содержание драгметаллов для каждой единицы отдельно, 1С очень сильно просаживается в производительности.
Не утрируйте. Биллинг - тоже финансы. Но попробуйте на 1С поднять биллинг электроэнергии с АСКУЭ даже не для МосЭнергоСбыта, а хотя бы для Тульской или Ярословской областей.
Странно видеть описание протокола четвертьвековой давности. Например, gRPC у него выигрывает по всем статьям.
И сколько раз еще за эти данные потом платили выкуп? Или их после получения выкупа кому-то продали?
Моя задача - чтобы заказчик был удовлетворен и закрыл акты. По результатам этот заказчик мне даже благодарственное письмо прислал )
Ну а я, в свою очередь, пообщавшись напрямую с заказчиком, понимал что и для чего я делаю. Что тоже немаловажно.
Ключевое слово "сеньеров". То есть, специалист, который кроме php знает SQL, Redis, Kafka, ClickHouse, gRPC/Protobuf/Swagger, k8s, RabbitMQ, SSL/TLS, HTTP/2, Kerberos/Oauth/Openid и т.п. А даже хорошее знание только языка программирования - это лишь джун+.
Просто разработчик не всегда аналитик. И наоборот. Но с опытом это приходит.
Последняя "дичь" была у меня - требование прогнозировать временной ряд по среднему арифметическому. До сих пор добавляются фильтрации, валидации, ограничения периода и т.п. Не то что на NN или ARIMA, даже на медиану не были согласны, при этом признавая, что точность прогноза будет выше, а вероятность ошибки при учете сезонности - ниже. Как выяснилось, всё потому, что зам. директора хочет иметь возможность самостоятельно проверять прогнозы, а ни о каких медианах и аримах он не знает и знать не хочет. Ну что, "любой каприз за деньги заказчика". )
Ну есть еще возраст. Меня под 60 стали куда-то звать намного реже, чем лет 10 назад. А самостоятельно работу я искал всего пару раз в далекой юности. Все остальные смены работы происходили по горизонтальным связям без всякого отсева и с фиктивными собеседованиями.
То есть, предлагается в течении нескольких месяцев, если не года изучать "java,Javascript,python,android,Linux,windows,opencv,ML,opticflow,SQL,qt/qml,rust,c/c++,с#,dsp,delphi", а за это еще и деньги платят? Для джуна, кое-как освоившего только C++, выглядит совсем неплохо )
Обратите внимание, что я изначально не указывал конкретные языки, а выше привел их лишь для примера. Я указал список, который позволит адаптироваться почти на любом проекте.
Так про то и речь, что только с Java по горизонтальным связям выбор будет в несколько раз меньше, чем если к Java добавить хотя бы C/C++ или Rust, Python или Perl, ну и SQL.
Например, на последнем месте, меня взяли на 80% C#, T-SQL и PL/pgsql, но при этом обязательно требовалось знание R и Python. А по ходу дела выяснилось, что необходимо еще дорабатывать sink для Kafka на Java, несколько OpenSource на C и, в качестве вишенки на торт, некоторое количество legacy на Perl. И именно по горизонтальным связям меня сюда и заманили, зная, что я со всем этим справлюсь.
А они не нужны для вышеописанных трех сценариев выборки одной записи.
Я же указал выше, что фрагментированность всё равно будет. Причем сам Oracle даже не будет знать, где в файле заканчивается один экстент и начинается другой. И, тем более, ничего не знает о sunit и swidth, что весьма актуально уже для любого RAID, в том числе и на SSD.
СУБД тоже об этом мало знает. Обычно, только в рамках одной транзакции. Но и файловая система будет сбрасывать кеш на диск только после завершения транзакции и получения sync(), а лишь тогда аллоцировать место на диске под закешированные данные. При этом статистикой записи в каждый файл она тоже располагает, эвристически вычисляя allocsize в каждом случае.
Это называется delayed allocation.
А это copy-on-write.
Я даже более скажу, современные СХД с WAFL или подобными приемами сами эффективно такие проблемы решают.