Для тех кто не знает, 1С:Предприятие – это среда для быстрой разработки кросс-платформенных бизнес-приложений и runtime для их выполнения в разных ОС и СУБД. В общих чертах в состав продукта входят:
- Кластер серверов приложений, работает на Windows и Linux
- Клиент, работающий с сервером по http(s) или по собственному бинарному протоколу, работает на Windows, Linux, macOS
- Веб-клиент, работающий в браузерах Chrome, Internet Explorer, Microsoft Edge, Firefox, Safari (написан на JavaScript)
- Среда разработки (Конфигуратор), работает на Windows, Linux, macOS
- Инструменты администрирования серверов приложений, работают на Windows, Linux, macOS
- Мобильный клиент, подключающийся к серверу по http(s), работает на мобильных устройствах под управлением Android, iOS, Windows
- Мобильная платформа — фреймворк для создания оффлайновых мобильных приложений с возможностью синхронизации, работающих на Android, iOS, Windows
- Среда разработки 1C:Enterprise Development Tools, написана на Java
- Сервер Системы Взаимодействия
Мы стараемся по максимуму писать один код для разных ОС — кодовая база сервера общая на 99%, клиента — примерно на 95%. Технологическая платформа 1С:Предприятие преимущественно написана на C++ и ниже приведены приблизительные характеристики кода:
- 10 миллионов строк С++ кода,
- 14 тысяч файлов,
- 60 тысяч классов,
- полмиллиона методов.
И все это хозяйство надо было перевести на C++14. О том, как мы это делали и с чем столкнулись в процессе, мы сегодня и расскажем.
Дисклеймер
Все написанное ниже о медленной/быстрой работе, (не)большом потреблении памяти реализациями стандартных классов в различных библиотеках означает одно: это справедливо ДЛЯ НАС. Вполне возможно, для ваших задач стандартные реализации подойдут наилучшим образом. Мы же отталкивались от своих задач: брали типичные для наших клиентов данные, прогоняли на них типичные сценарии, смотрели на быстродействие, объем потребляемой памяти и т.п., и анализировали – устраивают ли нас и наших клиентов такие результаты или нет. И поступали в зависимости от.
Что у нас было
Изначально мы писали код платформы 1С:Предприятие 8 на Microsoft Visual Studio. Проект начался в начале 2000-х и у нас была версия только под Windows. Естественно, с тех пор код активно развивался, многие механизмы были полностью переписаны. Но код писался по стандарту 1998 года, и правые угловые скобки у нас были разделены пробелами, чтобы успешно проходила компиляция, вот так:
vector<vector<int> > IntV;В 2006 году, с выходом версии платформы 8.1, мы начали поддерживать Linux и перешли на стороннюю стандартную библиотеку STLPort. Одной из причин перехода была работа с широкими строками. В нашем коде мы повсеместно используем std::wstring, основанный на типе wchar_t. Его размер в Windows 2 байта, а в Linux по умолчанию 4 байта. Это приводило к несовместимости наших бинарных протоколов между клиентом и сервером, а также различных персистентных данных. Опциями gcc можно указать, чтобы размер wchar_t при компиляции был тоже 2 байта, но тогда об использовании стандартной библиотеки от компилятора можно позабыть, т.к. она использует glibc, а та в свою очередь скомпилирована под 4-байтный wchar_t. Другими причинами были более качественная реализация стандартных классов, поддержка хеш-таблиц и даже эмуляция семантики перемещения внутри контейнеров, которой мы активно пользовались. И еще одной причиной, как говорится last but not least, была производительность строк. У нас был свой класс для строк, т.к. у нас в силу специфики нашего софта строковые операции используются очень широко и для нас это критично.
Наша строка основана на идеях оптимизации строк, высказанных ещё в начале 2000-х Андреем Александреску. Позднее, когда Александреску работал в Facebook, с его подачи в движке Facebook была использована строка, работающая на схожих принципах (см. библиотеку folly).
В нашей строке использовались две основные технологии оптимизации:
- Для коротких значений используется внутренний буфер в самом объекте строки (не требующий дополнительной аллокации памяти).
- Для всех остальных используется механика Copy On Write. Значение строки хранится в одном месте, при присвоении/модификации используется счетчик ссылок.
Чтобы ускорить компиляцию платформы, мы исключили из своего варианта STLPort реализацию stream (который мы не использовали), это дало нам ускорение компиляции примерно на 20%. Впоследствии нам пришлось ограниченно использовать Boost. Boost активно использует stream, в частности, в своих сервисных API (например, для логирования), поэтому нам приходилось модифицировать его, исключая из него использование stream. Это, в свою очередь, затрудняло нам переход на новые версии Boost.
Третий путь
При переходе на стандарт C++14 мы рассматривали такие варианты:
- Поднимать модифицированный нами STLPort на стандарт C++14. Опция очень непростая, т.к. поддержка STLPort была прекращена в 2010 году, и поднимать весь его код нам пришлось бы самостоятельно.
- Переход на другую реализацию STL, совместимую с C++14. Крайне желательно, чтобы эта реализация была под Windows и Linux.
- Использовать при компиляции под каждую ОС встроенную в соответствующий компилятор библиотеку.
Первый вариант был отвергнут сразу из-за слишком большого объема работ.
Мы некоторое время думали над вторым вариантом; в качестве кандидата рассматривали libc++, но он на тот момент не работал под Windows. Чтобы портировать libc++ на Windows, пришлось бы проделать немало работы — например, писать самим всё, что связано с потоками, синхронизацией потоков и атомарностью, поскольку в libc++ в этих областях использовалось POSIX API.
И мы выбрали третий путь.
Переход
Итак, нам предстояло заменить использование STLPort на библиотеки соответствующих компиляторов (Visual Studio 2015 для Windows, gcc 7 для Linux, clang 8 для macOS).
К счастью, наш код писался в основном по гайдлайнам и не использовал всяческие хитрые трюки, так что миграция на новые библиотеки протекала сравнительно гладко, с помощью скриптов, заменяющих в исходных файлах имена типов, классов, неймспейсов и инклюдов. Миграция затронула 10 000 исходных файлов (из 14 000). wchar_t заменялся на char16_t; мы решили отказаться от использования wchar_t, т.к. char16_t на всех ОС занимает 2 байта и не портит совместимость кода между Windows и Linux.
Не обошлось без небольших приключений. Например, в STLPort итератор можно было неявно скастить к указателю на элемент, и в некоторых местах нашего кода это использовалось. В новых библиотеках так делать было уже нельзя, и эти места приходилось анализировать и переписывать вручную.
Итак, миграция кода закончена, код компилируется для всех ОС. Настало время тестов.
Тесты после перехода показали проседание производительности (местами до 20-30%) и увеличение потребляемой памяти (до 10-15%) по сравнению со старой версией кода. Это было, в частности, связано с неоптимальной работой стандартных строк. Поэтому строку нам опять пришлось использовать свою, слегка доработанную.
Также вскрылась интересная особенность реализации контейнеров во встраиваемых библиотеках: пустые (без элементов) std::map и std::set из встроенных библиотек аллоцируют память. А у нас в силу особенностей реализации в некоторых местах кода создается довольно много пустых контейнеров этого типа. Аллоцируют стандартные контейнеры памяти немного, для одного корневого элемента, но для нас это оказалось критичным – на ряде сценариев у нас ощутимо упала производительность и выросло потребление памяти (по сравнению с STLPort). Поэтому мы заменили в нашем коде эти два типа контейнеров из встроенных библиотек на их реализацию от Boost, где эти контейнеры не имели такой особенности, и это решило проблему с замедлением и повышенным потреблением памяти.
Как часто бывает после масштабных изменений в больших проектах, первая итерация исходников работала не без проблем, и тут нам сильно пригодились, в частности, поддержка отладочных итераторов в Windows-реализации. Шаг за шагом мы двигались вперед, и к весне 2017 (версия 8.3.11 1С:Предприятия) миграция была завершена.
Итоги
Переход на стандарт С++14 занял у нас около 6 месяцев. БОльшую часть времени над проектом работал один (но очень высококвалифицированный) разработчик, а на финальной стадии подключились представители команд, ответственных за конкретные области — UI, кластер серверов, средства разработки и администрирования и т.д.
Переход сильно упростил нам работу по миграции на новейшие версии стандарта. Так, версия 1С:Предприятие 8.3.14 (в разработке, релиз запланирован на начало следующего года) уже переведена на стандарт С++17.
После миграции у разработчиков появилось больше возможностей. Если раньше у нас была своя доработанная версия STL и один неймспейс std, то теперь у нас в неймспейсе std находятся стандартные классы из встроенных библиотек компилятора, в неймспейсе stdx – наши, оптимизированные для наших задач строки и контейнеры, в boost – свежая версия boost. И разработчик использует те классы, которые оптимально подходят для решения его задач.
Помогает в разработке также и «родная» реализация конструкторов перемещения (move constructors) для ряда классов. Если у класса есть конструктор перемещения и этот класс помещается в контейнер, то STL оптимизирует копирование элементов внутри контейнера (например, когда контейнер расширяется и надо изменить capacity и реаллоцировать память).
Ложка дегтя
Самое, пожалуй, неприятное (но не критичное) последствие миграции — мы столкнулись с увеличением объема obj-файлов, и полный результат билда со всеми промежуточными файлами стал занимать по 60 – 70 Гб. Такое поведение связано с особенностями современных стандартных библиотек, ставших менее критично относиться к объему генерируемых служебных файлов. Это не влияет на работу скомпилированного приложения, но доставляет ряд неудобств в разработке, в частности, увеличивает время компиляции. Повышаются также требования к свободному месту на диске на билдовых серверах и на машинах разработчиков. Наши разработчики параллельно работают над несколькими версиями платформы, и сотни гигабайт промежуточных файлов иногда создают трудности в работе. Проблема неприятная, но не критичная, ее решение мы пока отложили. Как один из вариантов ее решения рассматриваем технику unity build (ее, в частности, использует Google при разработке браузера Chrome).
Комментарии (162)
PeterG Автор
13.11.2018 10:44В статье мы старались описать — почему и зачем переводили.
Возможно, не вполне удачно?
Переход на новый стандарт, как мы предполагали, позволил бы нам писать многие вещи элегантней, проще и надежней, упрощал поддержку и сопровождение кода.
И мы не ошиблись.
См. также раздел «Итоги» статьи, в частности
После миграции у разработчиков появилось больше возможностей. Если раньше у нас была своя доработанная версия STL и один неймспейс std, то теперь у нас в неймспейсе std находятся стандартные классы из встроенных библиотек компилятора, в неймспейсе stdx – наши, оптимизированные для наших задач строки и контейнеры, в boost – свежая версия boost. И разработчик использует те классы, которые оптимально подходят для решения его задач.
netricks
13.11.2018 11:01А если старый код остаётся в неизменном виде, но его изменение при поддержке и доработке производятся с применением новых возможностей? Приводит ли такой подход к каким-то затруднениям?
PeterG Автор
13.11.2018 11:13Да, приводит — новые версии компиляторов могут перестать (и перестают) компилировать код, написанный по старым стандартам :(
Использовать новые возможности, имея часть кода в старом стандарте, часто очень затруднительно, а иногда просто невозможно.0xd34df00d
13.11.2018 21:44Да, приводит — новые версии компиляторов могут перестать (и перестают) компилировать код, написанный по старым стандартам :(
Вы всерьёз с этим сталкивались?
Не, я тоже могу с этим столкнуться, если очень захочу, но в среднем комитет по стандартизации очень успешно решает проблему обратной совместимости.
Sander80
13.11.2018 22:09+2Не знаю, как там у 1с, но когда я переводил один свой проект (наука, консольное приложение), то переключение на c++11 привело к ошибкам при компиляции старого кода, потребовались исправления, прежде чем оно завелось. И, хуже того, если я не путаю, были места, которые компилировались, но привели к другому поведению.
С другой стороны, после того, как оно завелось, дало сразу процентов 20 прироста производительности.0xd34df00d
13.11.2018 22:11Дабы точно уточнить: вы взяли тот же компилятор той же версии, но просто поменяли флаг стандарта, или это было параллельно со сменой компилятора?
Sander80
13.11.2018 22:21+1Компилятор той же версии.
Или даже несколько компиляторов той же версии (зависит от машины)
Сейчас уже не восстановлю детали, но ломалось именно из-за флага стандарта.0xd34df00d
14.11.2018 02:41+2Жаль, что восстановить не удастся, мне было бы действительно очень интересно столкнуться с подобным в реальном коде.
Whuthering
16.11.2018 20:46И, хуже того, если я не путаю, были места, которые компилировались, но привели к другому поведению.
Вот тут важный вопрос: они привели к другому поведению из-за изменения стандарта, или там изначально было undefined behavior, и то что оно раньше работало лишь результат чистого везения?Sander80
16.11.2018 21:06Пытался сейчас найти по логу коммитов. Наверное, все-таки undefined. Но не в привычном смысле «работает или крашится», а в том, что там изменялся порядок разрешения некоторых соотношений, что в определенных примерах привело к провалу производительности, и пришлось вводить уже конкретику.
immaculate
13.11.2018 11:14Я уже 100 лет не писал на C++, но вот такой вопрос: использование
char16_tне добавит головной боли пользователям, если вдруг им понадобится вбивать имена или названия на китайском, лаосском, кхмерском и прочих экзотических алфавитах?PeterG Автор
13.11.2018 11:47Не добавит, у нас уже есть внедрения на языках, которые не влезают в 2 байта (китайский, вьетнамский).
qw1
13.11.2018 21:32+2И что в этом случае происходит? Нельзя ввести символ, или символ занимает два char16_t?
PeterG Автор
14.11.2018 09:48+2Символ занимает два char16_t, как и положено по стандарту unicode для utf-16.
tangro
14.11.2018 13:26А почему решили не переходить на UTF-8?
webhamster
16.11.2018 13:41Видимо, по той же причине, почему и Microsoft в свое время выбрала UTF-16 для большинства внутренних представлений строк.
UTF-8 дает универсальность, а UTF-16 — скорость обработки. Для 1С скорость обработки оказалась в приоритете.tangro
16.11.2018 14:34Универсальность дают обе кодировки, а скорость обработки латинских символов у UTF-8 выше. Сказался тут, видимо, целевой рынок. Основной массив текстов в самом 1С (и его базах) — на русском и обработка русского языка в UTF-16 и правда будет быстрее. Что двигало майкрософтом — черт его знает, точно не то, что Linux-миром.
Ryppka
16.11.2018 14:41+1Сказалась история. Когда «гранды» (MS, IBM и т.д.) переходили на юникод, он вмещался в 16 бит. А потом стало поздно.
Sabubu
13.11.2018 23:50Китайский алфавит в основном влезает в 2 байта. Больше 2 байт требует всякая экзотика, исторические виды письменности, а также эмотиконы. Вот с ними у 1С могут быть проблемы, если она не поддерживает суррогатные пары (кодирование символа в виде пары 2-байтных «символов» UTF-16).
Sterpa
13.11.2018 11:24+1Две вещи выглядят не логично:
1. Почему вы не использовали везде максимальный размер wchar_t из существующих систем = 4 байта? Эффективность расширения стандарта на порядок выше, чем при его урезании.
2. Если вы уже пришли к использованию компилятора GCC для Linux, то как же вас угораздило продолжить компилировать в VS2005 под Win?? Вы же могли компилировать под обе платформы используя одну версию GCC. Сколько головной боли ушло бы с упразднением третьего компилятора, 2 против 3.PeterG Автор
13.11.2018 11:501. 4 байт на один символ это слишком большой оверхид для наших приложений. У нас очень много строк живут в памяти и они могут занимать существенный процент от общего потребления
2. Visual C++ это до сих пор наилучший выбор при компиляции под Windows. GCC не обеспечивает инфраструктуру для продуктивной и комфортной работы под Windows.Sterpa
13.11.2018 12:07+11. Возможно… здесь вам точно виднее.
2. Я, разумеется, снимаю шляпу перед вашим профессионализмом, и вашего главного специалиста по С++, которого вы упомянули вначале статьи, но, по-моему, тут имеет место заблуждение…
В IDE Visual Studio (как инфраструктуре для продуктивной и комфортной работы) вы можете использовать любой компилятор, и CLang и GCC и MSVC.
Но начиная с C++11 GCC "превосходит любую доступную версию MSVC по качеству сгенерированного кода", это очевидная аксиома… Плюс именно своевременная и грамотная поддержка новых стандартов C++ и является главной вишенкой на GCC, как не парадоксально это бы ни звучало (мол как сам Microsoft может запаздывать со своим же компилятором!? Вот так и может и завидно регулярно.).
Но тут, разумеется, вопрос не в убеждениях. Надо компилировать и сравнивать производительность. Просто несколько огорчает, что в 2018 году вот так на веру берется MSVC, да еще для такого мега-кроссплатформенного национального проекта… как-то это не современно, на мой взгляд.PeterG Автор
13.11.2018 12:19Надо компилировать и сравнивать производительность. Просто несколько огорчает, что в 2018 году вот так на веру берется MSVC
А где в статье сказано про веру? ;)
MSVC был выбран по объективным причинам.
Одна из основных причин — отладочная информация и отладчик. GCC не умеет генерировать полноценные pdb чтобы использовать отладчик из Visual Studio или WinDBG. И при этом не имеет отладчика под Windows. Далее, все остальные инструменты под Windows, профилировщики и прочее работают только с pdb.
То же самое относится и к clang.
Качество сгенерированного кода msvc нас устраивает более чем, для нашей кодовой базы оно даже в каких-то случаях лучше, нежели в gcc под Linux.Sterpa
13.11.2018 16:01+1Вот тут ответ ваш не понятен, очень хотелось бы поподробнее.
В чем именно неполноценность генерации pdb в GCC? Если может помните на вскидку, вот прямо пример, что такого вам не выгрузил в pdb GCC 7?
Насколько я помню, время проприетарного PDB от Microsoft и форматов STABS или DWARF-2 от GNU tools прошло году эдак в 2010.
Сейчас GCC выдает стандартный PDB, а для любых сред, кроме Win, по сути дела всегда применяется отладчик GDB.
Для VisualStudio, пожалуйста, используйте WinGDB, уже стало классикой, по-моему.
У JetBrains свой встроенный GUI для GDB.
Из таблицы хорошо видно, что если закрыть глаза на CLang (тут я, увы, не специалист), то вы могли вообще для всех сред использовать одну единственную среду разработки с одним компилятором и отладчиком. Да вы просто могли поднять уровень разработки на уровень БОГ! в плане унификации))
И если в очередном C++, например, меняется реализация std::map, и единственный компилятор GCC начинает с ключом оптимизации __attribute__((optimize(«O3»))) аллоцировать память, а без ключа — нет, то это поведение становится ПРЕДСКАЗУЕМО для всех платформ, под которые вы работаете.PeterG Автор
13.11.2018 16:51+9PDB до сих пор закрытый формат Microsoft (без документации) и его в полном объеме не умеет генерировать ни gcc, ни clang, насколько нам известно. Хотя подвижки есть, и Microsoft выкладывала хедера по структуре PDB файлов на github.
Отладчик Visual Studio является основным инструментом под Windows для нас и тут мы наталкиваемся на проблемы с поддержкой pdb.
Использовать одну и ту же среду во всех случаях — это нереально. Ведь у нас помимо Windows также есть Linux, macOS, веб-клиент, Android и iOS.gecube
13.11.2018 17:27Использовать одну и ту же среду во всех случаях — это нереально. Ведь у нас помимо Windows также есть Linux, macOS, веб-клиент, Android и iOS.
смотря что называть под средой. IDE — да, реально. Весь тулкит (включая отладчики/компиляторы) — вряд ли, но ситуация уже лучше, чем 10-20 лет назад.
Sabubu
13.11.2018 23:56+2Gcc генерирует отладочную информацию в формате DWARF. Майкрософтовские инструменты, включая VisualStudio, WinDBG, DrWatson (хрень, которая показывается при падении программы и предлагает отправить отчет об ошибке) используют формат CodeView в контейнере PDB.
Хорошая новость — в clang сделали пробную версию генератора PDB, не без помощи Майкрософт, открывшей информацию по PDB. Но все это пока на ранней стадии.
Мне конечно использование gcc/mingw тоже нравится больше. Ими можно компилировать из-под линукса, из разных автоматизированных систем, итд.
Если у вас есть много свободного времени, вы можете расковырять генератор PDB от clang и прикрутить его к gcc для решения проблемы отладки.PleaseKING
14.11.2018 00:13+7Если у вас есть много свободного времени, вы можете расковырять генератор PDB от clang и прикрутить его к gcc для решения проблемы отладки.
А можно просто компилировать под MSVC и свободное время потратить на что-то более приятное :) Что, видимо, 1С и делает.
Sergey_Cheban
14.11.2018 09:22При такой унификации есть риск слишком сильно привязаться к особенностям конкретного компилятора. А потом, при переходе на новую версию компилятора (или на другой компилятор), могут возникнуть проблемы.
Лучше с самого начала не закладываться на особенности компилятора, не создавать технический долг, который рано или поздно придётся выплачивать.
mittorn
16.11.2018 11:48есть конвертер из dwarf в pdb:
github.com/rainers/cv2pdb
уже давно использую его чтобы выводить красивый стектрейс через dbghelp
0xd34df00d
13.11.2018 21:47+2Плюс именно своевременная и грамотная поддержка новых стандартов C++ и является главной вишенкой на GCC
По части своевременной (хотя это сейчас более-менее выровнялось) и, что самое главное, грамотной поддержки clang всё-таки опережает. По крайней мере, я на баги в реализации стандартов в gcc натыкался существенно чаще, чем в clang.
ilammy
13.11.2018 14:42Почему вы не использовали везде максимальный размер wchar_t из существующих систем = 4 байта? Эффективность расширения стандарта на порядок выше, чем при его урезании.
Использование wchar_t не означает автоматически правильную обработку строк без каких-либо усилий со стороны программиста. При работе со строками нельзя забывать, в какой кодировке они находятся.
Если взять Юникод, то один даже четырёхбайтовый wchar_t не способен представить все графемы таким образом, чтобы не оставить возможностей для ошибки. Как минимум, популярные ныне эмоджи могут требовать нескольких code points.
Поэтому при прочих равных лучше уж взять тип данных, размер и семантика которого не зависит от платформы, под которую собирается код.
Infactum
13.11.2018 14:48Символы юникода и их размер это прямо классика. Вот эталонная статья Спольски от 2003 года еще.
Sterpa
13.11.2018 16:08+1В 2018 году использование НЕ Юникода? это преступление против человечности… абсурд просто.
ilammy
13.11.2018 18:01+1Реальный мир часто абсурден. Хотя лично я тоже убеждённый сторонник повсеместного использования Юникода для представления текстов, но есть некоторые вещи, которые Юникод представить не в состоянии. Вроде некоторых имён. Однако, это не технический вопрос об устройстве стандарта, а больше вопрос администрирования консорциума, который отказывается добавлять в стандарт редко используемые или «повторяющиеся» символы.
Также с не-Юникодом точно придётся контактировать на границах системы, за которыми бушуют океаны легаси-кодировок, будь то файлы в КОИ-8 или HTTP, который по умолчанию использует Latin-1.
Meloman19
14.11.2018 11:18Если взять Юникод, то один даже четырёхбайтовый wchar_t не способен представить все графемы таким образом, чтобы не оставить возможностей для ошибки. Как минимум, популярные ныне эмоджи могут требовать нескольких code points.
4 байта (UTF-32) как раз полностью покрывает весь Unicode. Выбор размера char влияет лишь на способ представления, но не на сами символы, поэтому в UTF-16 приходится использовать суррогатную пару. Более того, использование UTF-32 как раз лишает программиста головной боли связанной с обработкой текста, как набора Unicode символов, поскольку в таком случае у тебя в памяти лежит массив char'ов, где каждый char — это конкретный символ Unicode.
Все неприятности начинаются уже при работе непосредственно с самим Unicode.
Если опустить проблемы связанные с поддержкой новых версий стандарта, когда твоя библиотека тупо может не знать о существовании каких-нибудь новых диапазонов, то всплывает, например, проблема комбинирования символов.
С одной стороны, не так может оказаться страшно, если комбинацию нескольких символов можно с помощью алгоритмов нормализации привести к одному символу того же Unicode. Как в примере с википедии:
й и? — первая буква состоит из 1 unicode символа, а вторая — из 2. (можете скопировать в блокнот, сохранить в UTF-16 и посмотреть в HEX)
Но вот уже проблемой становится, когда попадается нестандартные комбинации, типа «белая женщина-врач», являющейся комбинацией символов «женщина» (U+1F469), «модификатора — белый цвет» (U+1F3FB), «символ медицины» (U+2695) и zero-width joiner (U+200D) между ними. Такая комбинация вообще не декларируется стандартом и эмодзи такого в Unicode нет по понятным причинам.ilammy
14.11.2018 13:57Более того, использование UTF-32 как раз лишает программиста головной боли связанной с обработкой текста, как набора Unicode символов, поскольку в таком случае у тебя в памяти лежит массив char'ов, где каждый char — это конкретный символ Unicode.
Вот именно что не решает. Как раз из-за комбинаций, образующих одну визуальную единицу. Когда я выделяю в текстовом поле «???» — а что вы видите в своём браузере? что хабраредактор сделал с моим текстом? — и копирую этот символ, то обычно ожидается, что скопируются все четыре code points, из которых он состоит:
- U+1F469 WOMAN
- U+200D ZERO WIDTH JOINER
- U+2695 STAFF OF AESCULAPIUS
- U+FE0F VARIATION SELECTOR-16
Не один
wchar_t, а четыре. Откуда-то текстовое поле должно знать, что в этом конкретном случае надо поступать именно так. Здесь, правда, ситуация немного натянутая: текстовое поле как бы занимается отображением текста, так что оно-то и так в курсе, сколько визуального места занимает каждая последовательность байтов, кодирующая тот или иной текст.
Программист здесь может ошибиться, например, в операции «взять первый символ» в строке, реализовав её как
string[0]. Если используется UTF-8, то эта операция вернёт некорректный UTF-8 текст из одного байта 0xF0. Если используется UTF-32, то эта операция даст технически корректный текст, но будет семантически неверной, так как потеряет все пришлёпнутые сзади модификаторы.
Юникод — это фундаментально кодировка с переменной длиной графем. Работать с текстом в основном надо либо на визуальном уровне графем (иногда их частей) для отображения и редактирования, либо на уровне байтов для передачи и хранения. Формат представления никак не помогает правильно работать с графемами: что в UTF-32, что в UTF-8 надо знать отдельные правила их обработки. В любом случае для обработки графем придётся жить с тем, что один условный
charв массиве не соответствует одной графеме.
Для передачи и хранения вообще удобнее работать как раз с массивом байтов, так как длина массива байтов в байтах и порядок байтов в байте не зависит от операционной системы, архитектуры процессора и компилятора. С этой точки зрения UTF-8 является идеальным форматом. У UTF-16 есть преимущество в компактности для текстов на языках, символы которых в UTF-8 кодируются тремя байтами. (Плюс, есть исторически сложившиеся API, принимающие именно UTF-16.) У UTF-32… есть много лишнего места, разве что. Это удобное промежуточное представление для преобразований между форматами, но для хранения и обработки UTF-32 подходит не очень.
gecube
14.11.2018 14:38Насчет экспертизы UTF-32 — полностью согласен. Не понимаю, зачем тратить в два раза больше места, если можно все кодировать в UTF-16. UTF-8 скорее всего смысла не имеет именно потому что кириллица в нем не может быть отражена одим байтом…
Meloman19
14.11.2018 19:00Я и не говорю, что UTF-32 решает проблему вывода графем, но то, что с ним не легче работать, чем с UTF-16 или UTF-8…
Юникод — это же в первую очередь таблица «индекс — символ», а проблема вывода лежит в области обработки массива таких индексов.
Согласитесь, что проще оперировать голыми int'ами, как в случае той же «женщины-врача» — это по сути конкретная последовательность {0x1F469, 0x200D, 0x2695, 0x200D, 0xFE0F}. При обработке, в таком случае, нас ждёт всего одна операция — поиск такой последовательности в массиве. В случае же работы с каким-нибудь UTF-8 перед тем, как искать последовательность потребуется перекодировать данные для получения опять же набора int'ов.
Только не подумайте, что я топлю за использование 4 байтов. Накладные расходы на хранение таких данных, особенно при работе с большим количеством строк, как тут — это слишком.ilammy
14.11.2018 19:43+2В случае UTF-8 поиск и замена выполняется настолько же просто. Только у вас массив байтов и искать там надо последовательность {0xF0, 0x9F, 0x91, 0xA9, 0xE2, 0x80, 0x8D, 0xE2, 0x9A, 0x95, 0xE2, 0x80, 0x8D, 0xEF, 0xB8, 0x8F}. Что так искать последовательность, что эдак.
Только когда приходит время отправлять текст в сеть или записывать его на диск — а они работают только с байтами — в случае UTF-32 приходится выбирать, записать U+1F469 как {0x00, 0x01, 0xF4, 0x69} или как {0x69, 0xF4, 0x01, 0x00}, аналогично для UTF-16 — {0xD8, 0x3D, 0xDC, 0x69} или {0x3D, 0xD8, 0x69, 0xDC}, тогда как в UTF-8 вариант только один: {0xF0, 0x9F, 0x91, 0xA9}.Meloman19
14.11.2018 20:59Ну вот, вместо понятной последовательности индексов используем массив «каких-то» байт. А ведь при выводе помимо такой замены проводится ещё и нормализация, которая проводится через преобразование в UTF-32 и обратно. Во всяком случае в тех реализациях, что я видел — это так.
А ещё можно вот какой финт сделать в UTF-32:
1) Нормализуем.
2) Заменяем все нестандартные последовательности на свои индексы из пользовательских диапазонов.
3) Теперь с таким массивом действительно можно работать, как с массивом визуальных единиц не боясь повредить данные.
И я понимаю, что проблема порядка байт остаётся, но я же говорю не о проблеме хранения и передачи, а об удобстве обработки таких данных.ilammy
15.11.2018 12:28С точки зрения алгоритма поиска между последовательностью индексов и последовательностью байтов разницы особой нет же. Оба вида последовательностей получаются из других строк текста, а не составляются вручную программистом. И для ренормализации строки после замены достаточно затронуть только несколько соседних символов, всю строку в UTF-32 преобразовывать не надо.
Идея с использованием неиспользуемых значений в UTF-32 интересная. В 4 байта же действительно можно разместить ещё 4096 дополнительных Юникодов, если использовать лишние битики. Не знаю, будет ли какой-то существенный выигрыш в производительности от такой замены и нестандартного представления, но идея однозначно интересная! Спасибо.
PleaseKING
13.11.2018 22:42+3По поводу второго пункта — очень странная идея использовать gcc везде, я бы еще понял, если бы вы clang предложили, но gcc после ухода с него андроида постепенно уходит в легаси. Симбиан и Маемо в 2018 году никому не нужны, ios — clang, андроид — clang, win — msvc или clang, linux — gcc или clang.
Ну и под вин ничего лучше msvc все же нет, несмотря на усилия clang (а не gcc) в этом плане. Как и лучше IDE, чем Visual Studio, при всем уважении к CLion. И по части стандартов msvc сильно подтянулся, хотя до clang не дотягивает.
Sterpa
14.11.2018 00:00-1Если рассматривать микропроцессоры как еще одну платформу, а это по истине гигантский рынок, то там все-таки преобладает GCC и перемен в строну CLang не ожидается. А вот переход на более изящный синтаксис C++ имеется, чипы растут в производительности и там, где раньше приходилось виртуозить на Си, периодически переходя на Асм, можно уже безболезненно использовать стандартные контейнеры из std.
Т.е. в плане унификации, сейчас GCC все же более удобен.
СLang — будем посмотреть))PleaseKING
14.11.2018 00:09+1Ну так как 1C на микроконтроллерах не работает и вряд ли будет, то это к теме поста отношения не имеет. Соглашусь, что в embedded gcc может быть и сильнее — не сильно погружен, не могу всерьез комментировать — но игнорировать iOS и Android тоже нельзя — а там gcc (уже) нет. Так что с тезисом про унификацию согласиться не могу.
При этом ее полезность тоже не стоит переоценивать — у нас в компании легко собирается продукт под gcc разных версий, clang разных версий и MSVC разных версий — наверное, 6 вариантов суммарно — и не могу сказать, чтобы это было как-то так уж сложно сейчас. Основные проблемы в АПИ платформы, а тут никакой компилятор не поможет.
Sterpa
13.11.2018 11:37И еще один момент, многие наработки из Boost для работы с контейнерами перекочевывают в C++17. Вам имеет смысл потом снова проверить аллокацию памяти для std::map|set, возможно проблема будет пофиксина (как минимум в GCC) и удастся снова вернуться к стандартным контейнерам.
bolonov
13.11.2018 12:06-1Спасибо. Стало понятнее что случилось со стабильностью релизов Платформы после 8.3.10 (так пока и сидим на нем из-за критичного бага со внешними источниками в режиме совместимости 8.2.13).
Даже демо платформы ( platform.demo.1c.ru/demo83 ) до сих пор не переведено на типа актуальную 8.3.13, а остается на 8.3.12.
Остается надеяться, что 1С в ближайшее время таки справится с проблемами, связанными с таким серьезным переходом.9thlevel
13.11.2018 15:51+2Зря человеку карму подпортили. Мы недавно пробовали перейти на 8.3.13 (конфигурации — управляемые приложения). Поплевались, психанули и откатились на 8.3.11.3034. Динамические списки ведут себя неадекватно, колонки съезжают. Веб-клиент (понимаю, что написан не на С++) постоянно ошибки выдает.
PeterG Автор
13.11.2018 16:04+1А в каких именно конфигурациях проблемы?
В типовых или в самописных?9thlevel
14.11.2018 03:40+1Самостоятельно разработанные конфигурации. Но по стандартам и методикам 1С, с нормализованной схемой БД.
Простой пример, динамический список ведет себя непредсказуемо как элемент формы — при клике позиционирует выбранную строку всегда посередине. Запрос дин. списка очень простой (выборка из документа даты, номера, автора). 95% процентов пользователей работают через веб-клиент. Если действительно интересны выявленные проблемы, могу еще раз провести тесты на 8.3.13 и передать результаты.PeterG Автор
14.11.2018 09:47+1Самостоятельно разработанные конфигурации.
Но по стандартам и методикам 1С,
При выходе новых версий платформы 1С публикует изменения стандартов.
Так что конфигурации может потребоваться модифицировать для работоспособности в новых версиях платформы.
с нормализованной схемой БД.
А это про что, можете пояснить?
В 1С объекты БД явно не создаются, это делает платформа, и в этот механизм вмешиваться не рекомендуется.
Простой пример, динамический список ведет себя непредсказуемо как элемент формы — при клике позиционирует выбранную строку всегда посередине. Запрос дин. списка очень простой (выборка из документа даты, номера, автора). 95% процентов пользователей работают через веб-клиент. Если действительно интересны выявленные проблемы, могу еще раз провести тесты на 8.3.13 и передать результаты.
Если не сложно — сделайте пожалуйста.
Воспроизведутся проблемы — шлите конфигурацию, будем чинить.9thlevel
14.11.2018 12:01При выходе новых версий платформы 1С публикует изменения стандартов.
Так что конфигурации может потребоваться модифицировать для работоспособности в новых версиях платформы.
Мы это учитывает.
А это про что, можете пояснить?
В 1С объекты БД явно не создаются, это делает платформа, и в этот механизм вмешиваться не рекомендуется.
В работу платформы на уровне SQL не лезем. Чтобы писать запросы, нужно понимать что из себя представляет БД 1С. А мы знаем, что это таблицы в СУБД. Поэтому при проектировании структуры объектов конфигурации оперируем понятием «таблица», но с использованием тонкостей 1С (периодичность регистров сведений, регистры остатков, оборотов и т.п.). Соответственно, приводим схему данных в такое состояние, когда у нас нету избыточности. Или нехватки данных (статья на ИТС про самодостаточность регистров).
Если не сложно — сделайте пожалуйста.
Воспроизведутся проблемы — шлите конфигурацию, будем чинить.
Хорошо. Результаты лучше в личку?
Tertium
13.11.2018 12:08-1Как вообще в проекте такой сложности и тяжести можно додуматься использовать стандартные контейнеры и потоки, которые мягко говоря, не оптимизированы? Ну разве что легаси. Но у меня бы в первую очередь это бы вызвало вопросы к коду, раз уж не жаль 6 месяцев работы сеньора на перевод на стандарт.
thauquoo
13.11.2018 12:36+2У меня бы к такому синьору, который сразу хочет выбросить стандартные контейнеры и потоки, тоже были бы вопросы. Например, попросил бы результат ы профилирования, которые демонстрируют, что именно в стандартных вещах узкое горлышко.
Tertium
13.11.2018 15:42+4Таки если вы читали статью — в них-то и узкое горлышко. Если у вас есть лишние люди, конечно, можно в проектах такого уровня зависеть от чужих либ в таких базовых вещах, но выглядит это странно. Я, разумеется, не стал бы переписывать библиотеку работы со звуком или чтения каких-то мудреных чужих форматов, но в игровых проектах я столько «изящной архитектуры и изящных конструкций» насмотрелся, которые надо оптимизировать тупо через массивы или переопределять new, чтобы хоть как-то работало. Так что перекопать базу и твердо на ней стоять — маст хэф. Праада на сях давно не писал, может std и правда стало мастерписом, но в мое время это был странный перешаблонированный и мешающий отладке монстр, к тому же скорее академический, чем для реального использования в хевилоаде.
thauquoo
13.11.2018 23:54+3Праада на сях давно не писал, может std и правда стало мастерписом
И за изменениями в новых стандартах и STL не следите? Если так, то претензии ещё более необоснованные. Для начала стоит актуализировать собственные знания.Tertium
14.11.2018 19:55Говорю же, давно не писал на сях и более ко мне stl:: не применим, к тому же давно потерял веру в человечество, а после бардака с многократным переворотом парадигмы мультипоточного кода у мелкософта, и вовсе стараюсь изо всех сил, где это аозможно, обходить зависимости от чужого кода или протоколов, если у проекта запланировано жизни более 2 лет.
Вообще, это наверное, с молодостью проходит — восторженныая радость при слежении за обновлениями и переворотом в технологиях. Со временем обновления ОС, IDE, библиотек и сервисов вызывают лишь чувство досады, иногда тревоги, иногда — испанского стыда, но больше просто легкое раздражение, что опять придетмя ковырять то, что давно в продакшне.
Sterpa
13.11.2018 12:46Это неверное утверждение, особенно в отношении контейнеров, для чего-то другого — возможно.
Как раз сейчас в С++ контейнеры особенно модернизируются. Например, для того, чтобы эффективно работала в С++17 вот какая изящная конструкция множественной итерации.
for (auto [x,y,z] : zip( xs, ys, zs )) { // ... }
Сейчас вы вынужденны применять для этой задачи все тот же сторонний Boost (реализация которого иногда тяжеловата, т.к. он опирается на существующие контейнеры, создавая над ними обертки)
for(auto&& t : zip_range(contA, contB)) { t.get<0>(items) = t.get<1>(items); }
И, кстати, для окончательного отказа от указателей, в пользу новых интеллектуальных указателей или модернизированных ссылок (С++17) также придется оптимизировать/переписать реализацию всего, где происходят итерации по массивам.
Infactum
13.11.2018 12:43А обновленные шаблоны native ВК в связи с переходом на новый стандарт стоит ждать?
PeterG Автор
13.11.2018 14:06+1Рассматриваем этот вопрос.
NativeAPI завязывается также на работу в браузере, а многие промышленные дистрибутивы Linux не спешат переходить на новые стандарты в используемых компиляторах. И, соответственно, ВК подключенная в браузере в таком дистрибутиве, может быть неработоспособна.
andreyle
13.11.2018 13:43В итоге-то новая версия стала работать быстрее или медленнее, что с памятью стало? Победили все первоначальные проблемы?
PeterG Автор
13.11.2018 14:10В итоге-то новая версия стала работать быстрее или медленнее, что с памятью стало?
Новая версия платформы на типовых сценариях работает не медленнее старой.
И потребляет при этом не больше памяти, чем старая.bolonov
13.11.2018 14:48+2И потребляет при этом не больше памяти, чем старая.
Коллеги на проф. форуме неоднократно описывали обратное. Например:
partners.v8.1c.ru/forum/t/1723890/m/1747082PeterG Автор
13.11.2018 15:24+1Новая версия платформы на типовых сценариях работает не медленнее старой.
И потребляет при этом не больше памяти, чем старая.
Перед релизом мы тестируем на типовых сценариях.
Когда нам присылают сценарии, на которых есть деградация по производительности/памяти — мы, по мере возможности, фиксим платформу и исправляем ситуацию.
Все возможные сценарии, как вы понимаете, перебрать в принципе невозможно.
Sway
13.11.2018 13:45И попутно угробили работоспособность конфигурации 1С: ЖКХ. И, вероятно, не только ее. Молодцы, что сказать. Про общую скорость работы я вообще промолчу, она все хуже и хуже.
PeterG Автор
13.11.2018 14:11+1И попутно угробили работоспособность конфигурации 1С: ЖКХ
А что случилось с 1С:ЖКХ на новой платформе?
Про общую скорость работы я вообще промолчу, она все хуже и хуже
На каких сценариях она все хуже и хуже?Sway
13.11.2018 14:261. Функционал связанный с подъездами и квартирами (может еще где, я не выискивал) полностью отвалился.
Ошибки:
{ВнешняяОбработка.МенеджерОбъектов.МодульОбъекта(9)}: (EObjectNotFound) Object «СЗК_ЗащищеннаяОбработка» is not found
{ВнешняяОбработка.МенеджерОбъектов.МодульОбъекта(9)}: (EBadFileFormat) Bad file format
Вылетает при попытке доступа к Зданиям при создании или редактировании.
2. Бухгалтера с каждым новым обновлением платформы поднимают вонь что так работать невозможно, что тормозит ужасно. Мне сравнивать не с чем, я так, по сути немного помогаю по мелочи, но и сам тыкаясь по разделам ощущаю что оно довольно медленно ворочается даже на почти пустой базе под ЖКХ, особенно при сохранении данных. При этом сервер на котором стоит платформа, БД и работают тонкие клиенты даже не напрягается. БД — SQL Server.PeterG Автор
13.11.2018 14:35+1А можете ссылку кинуть на конкретную конфигурацию на сайте производителя конфигурации?
Это что-нибудь из вот этого комплекса?
Или речь совсем о другом?
Конфигурация, насколько понимаю, не от 1С.Sway
13.11.2018 16:29Вот эта: vgkh.ru/jsk/jkh/capabilities.php
Перестала работать после обновления платформы до последней версии. Не помню, правда, какая то версия была. Сами разработчики конфигурации говорят что работает стабильно на 12й версии, а 13я глючная (это с их же слов). При этом откатиться назад нельзя т.к. станут несовместимы какие-то другие конфигурации.PeterG Автор
13.11.2018 17:07+5Вот эта: vgkh.ru/jsk/jkh/capabilities.php
Тут вопросы к разработчикам конфигурации.
Они декларировали совместимость конфигурации с той платформой, на которой появляются проблемы?
При этом откатиться назад нельзя т.к. станут несовместимы какие-то другие конфигурации.
Насколько знаю — можно поставить разные версии платформы даже на один сервер и разные конфигурации запускать под разными версиями платформы. Или у вас не та ситуация?Sway
13.11.2018 20:42Да кто ж его разберет теперь декларировали или нет. Проблема в том, что новый функционал по хорошему не должен убивать уже существующий как произошло в данном случае. И ладно бы версии были сильно разными, так нет же. С версией 2х-месячной давности оно работало, а с версией 3-4х недельной давности уже нет. Я не могу сказать какая была до этого версия, но знаю что обновления платформы ставятся подрядчиками оперативно. На сколько помню апдейт был в августе (на нем работало) и в октябре (уже не работает).
Вариант с разными версиями прекрасен во всей своей костыльности.
Все это звучит прямо как «мы тут что-то сломали, но это не наша проблема».
Вот реально платишь хренову тучу денег за гемор с лицензиями, с обновлениями, с сопровождением, с переносом данных и т.д. и т.п.
Я к этому всему имею немного косвенное отношение т.к. моя задача была перенести данные из существующей системы в 1С и потом это все интегрировать в кабинет пользователя. И понеслось…SergeyMax
13.11.2018 21:52+2Да кто ж его разберет теперь декларировали или нет
Дак тот, кто обновлял — тот и разберёт)
philya
14.11.2018 00:14+1Где туча денег? Если не обновлять конфигурации, то можно ничего не платить. Если обновлять то можно покупать итс.техно за 12500 в год. Это примерно 1 МРОТ. А для базовых версий обновления бесплатны. Вы уверены, что это туча денег?
Sway
14.11.2018 08:40Я про весь комплект включая лицензии на пользователей, конфигурацию, итс на платформу, итс на конфигурацию, лицензию на SQL Server. Еще приходится оплачивать услуги подрядчиков чтобы не иметь головняка с процессом обновления.
Про не обновлять конфигурацию, я надеюсь, вы пошутили… Конечно, можно в целях крайней экономии к этому варианту прийти, но тогда уж проще и дешевле использовать аналогичные продукты, если такие имеются на рынке.philya
14.11.2018 09:12ИТС на локальную сеть нужен один. Остальные лицензии — это разовые затраты, компьютер же бесплатно никто не дает? Обновление типовых конфигураций с появлением расширений можно доверить роботу, да расширения бывают отваливаются, но для меня это не критично. Не обновляться вообще? Легко на вмененке или упрощенке.
kovserg
13.11.2018 15:02-2Затраты на переписывания кода для получения новых проблем окупились?
Я так понял что основная проблема была «угловые скобки у нас были разделены пробелами». Зато теперь модно, молодёжно:
— увеличили потребление памяти (всеобщий тренд)
— стало требовать свежее железо для сборки (наконец-то можно обновить пакр)
— winxp в пролёте
— теперь нужны более дорогие специалисты для поддержки кодовой базы (а то лезут тут всякие)
— тесты стали тоже требовать больше ресурсов
— функционал тот же но исполняемый файл солиднее и капризней
— зато теперь можно использовать свежий boost (а не эти костыли)
«Небыло печали купила баба порося»: Кодовая база стала меньше? Время сборки уменьшилось? Время на устранение багов сократилось или стало более предсказуемым? Или просто доработать чтобы компилировалось и проходило тесты? В чем огромный плюс проведённо титанической работы особенно для клиента?
В целом ваш высококвалифицированный разработчик просто красавчик. Его плюсы затмевают ваши минусы. Предлагаю повысить ему зарплату.Whuthering
13.11.2018 17:44+12— увеличили потребление памяти (всеобщий тренд)
Разработчики прямым текстом здесь сказали, что после окончания работ потребление памяти на типовых сценариях не увеличилось, остальные моменты они фиксят при обнаружении.
— winxp в пролёте
ОС, первая версия в семестве которой вышла 17 лет назад, последняя (SP3) 10 лет назад, и официально снятая с поддержки производителем 4 года назад?
Не говоря уж о том, что современный MSVC прекрасно компилирует бинари под xp вне зависимости от стандарта языка, нужно просто соответствующий тулчейн выбрать.
— теперь нужны более дорогие специалисты для поддержки кодовой базы (а то лезут тут всякие)
Разработчик-плюсовик, засевший в 90-х годах и ничего не слышавший и не желающий слышать про актуальные стандарты его основного языка — это не «более дешевый» специалист, это просто плохой специалист.kovserg
14.11.2018 09:48+1MSVC прекрасно компилирует бинари под xp вне зависимости от стандарта языка, нужно просто соответствующий тулчейн выбрать.
Собирать то он собирает, но работать не будет. И никто с этим заморачиваться не захочет.
это не «более дешевый» специалист, это просто плохой специалист
Дело не в плохой/хороший. Сравните объём ненужного в новом стандарте, объём знаний который надо запихать в студента за ограниченное время. Думаете качество знаний в таких условиях тоже будет расти? Так что затраты на обучение новых специалистов будут непрерывно расти пока не придёт понимание что дорогонах.
Сделали бы уже новый С++ явно не совместимым со старым вместо того что-бы регулярно собирается и выдумывать как еще фишку прикрутить к 38 летнему старью, оставив старьём.
Ведь по факту получаем что каждый раз нужна работа по переводу кода на новый стандарт C++ разве это не странно при наличии обратной совместимости?gecube
14.11.2018 09:54-1Насчёт выкинуть с++ на свалку истории — полностью согласен.
сейчас набежит школота и скажет, что я ниосилятор. Да, признаю, просто невозможно успевать за развитием с++.
Просто есть баланс: латать по-чуть-чуть и прямо сейчас (получают маленькие проблемы, которые потихоньку можно править). Или переписать все, например, на той же Джава. И сколько человеко-часов единомоментно тогда придется потратить? К тому же, простого пути миграции с одной экосистемы языка на другую нет. Поэтому технический долг нарастает.
0xd34df00d
15.11.2018 03:42Сравните объём ненужного в новом стандарте, объём знаний который надо запихать в студента за ограниченное время.
Это что, например, ненужное? Кроме
std::launder.Ryppka
15.11.2018 08:46А почему Вы считаете std::launder ненужным?
0xd34df00d
15.11.2018 18:02Потому что ту задачу, которую он решает, можно было решить, отменив UB в соответствующей части стандарта, без существенного ущерба потенциалу для оптимизации.
Чтобы написать всё аккуратно, мне придётся снова примерно полчаса читать стандарт, чего делать не очень хочется.
kovserg
15.11.2018 12:20std::launder это очередной костыль, который помогает бороться очередным UB, который вызван новым стандартом, который позволяет компилятору использовать не обоснованную логику, которая используется при оптимизации в тех ситуациях где она нафиг не нужна (в доме который построил Страуструп)
Вообще это печально постоянно жертвуют здравым смыслом ради непонятно чего. И потом тыкают лозунгом мы не хотим платить за то что не используем. Зато потом за это платят все остальные.
gecube
13.11.2018 15:05+3интересная статья. Спасибо. Вопросы
- делали ли код-фриз на время переноса? Если нет, то не было потом проблем со слиянием багфиксов предыдущих релизов и крайней версии, перенесенной на новый тулинг С++?
- Используете ли техники статического анализа кода? Например, продукт PVS Studio www.viva64.com/ru/pvs-studio
- Не появилось ли проблем у пользователей при миграции между версиями? Т.к. бинарные данные изменили формат/layout или еще что-нибудь
PeterG Автор
13.11.2018 15:42+5Спасибо, мы старались!
1. Код-фриз не делали, работы над стволом и новым стандартом велись параллельно. После обновления, в некоторых случаях, конечно, есть проблемы переноса исправлений в старые версии платформы (без поддержки стандарта C++14).
2. Конечно используем на постоянной основе. PVS Studio основной инструмент.
3. Формат бинарных данных затронут не был. Только алгоритмы обработки. Так что проблем с этим не было.
sena
13.11.2018 15:41Тесты после перехода показали проседание производительности (местами до 20-30%) и увеличение потребляемой памяти (до 10-15%) по сравнению со старой версией кода. Это было, в частности, связано с неоптимальной работой стандартных строк. Поэтому строку нам опять пришлось использовать свою, слегка доработанную.
Любопытно. Если бы у Вас не было альтернативной реализации строки под рукой, то Вы бы никогда и не провели такой тест, верно?
Если это только отдельные места, где производительность просела до 20-30%, то может надо было эти места оптимизировать или даже (крамола!) кое-где забить на это? Всё-таки отказ от стандартной строки это серьёзный шаг.PeterG Автор
13.11.2018 15:49+3Всё-таки отказ от стандартной строки это серьёзный шаг.
Мы этот шаг сделали довольно давно :)
По моему опыту, любые проекты, много работающие со строками, используют свою реализацию строк, по ряду причин, не последняя из которых — быстродействие. Из того что видел сам — платформы двух больших западных ERP (это даже частично сам писал), и вот еще 1С. Из того, про что слышал — уже упомянутый Facebook, например.sena
14.11.2018 12:37А Вы не могли бы немного подробнее рассказать, на чём именно теряется быстродействие и память в Вашем случае? Конкретно интересует следующее: теоретически семантика перемещения при правильном применении в большинстве случаев должна свести на нет преимущества от COW. Но это сработает только если переписать код в соответствующем стиле. Можно предположить что переписывать код было слишком трудоёмко и поэтому было принято решение вернуться обратно к реализации на COW. Но возможно решающую роль сыграла оптимизация хранения коротких строк? Расскажите подробней, пожалуйста.
PeterG Автор
14.11.2018 15:25В нашем коде много мест, где происходит явное копирование строк и семантика перемещения там не сработает. Только COW. Но в других случаях, при работе с контейнерами, перемещение здорово помогает.
aFanOfSwift
13.11.2018 16:54-1А когда обновления нормально ставится будут? А то достало уже стандартную базу обновлять через конфигуратор. Обновления выходят чуть ли не раз в месяц. Оно еще и адски долго запускается.
Когда запуск ускорите? А то получается, как с MS Offise и LibreOffice. Первый запускается вечность, а второй на той же конфигурации раза в три быстрее при первом запуске и раз в 20 при повторном. Только вот у вас к сожалению конкурентов нет.
vsb
13.11.2018 17:55+1Раз уж используете свои строки, почему не UTF-8? Вроде сейчас это стандарт де-факто. На многих строках снизите потребление памяти.
sena
14.11.2018 14:51Пока автор отвечает, предположу что исторически так сложилось. Изначально основной платформой был Виндос, поэтому когда-то был выбран UCS-16. Сегодня переходить на другую кодировку мучительно больно — ведь нужно сохранять совместимость с предыдущими версиями, при этом заранее оценить величину выигрыша/проигрыша затруднительно.
PeterG Автор
14.11.2018 15:52Для преимущественно англоязычных данных UTF-8 имеет смысл, в нашем случае профит будет небольшой.
И потом, переход на UTF-8 может оказаться несравнимо тяжелее, нежели переход на новый стандарт, ситуацию нужно тщательно анализировать, учесть все возможные выигрыши и потери.
AVI-crak
13.11.2018 18:03-310 миллионов строк
Это безумно большая цифра для программного кода, с таким объёмом он уже должен обрести собственное сознание…
Возможно имелось в виду общее количество строк?
Вместе с пустыми хидерами со стандартной шапкой, отсутствием кода и смысла. Почти любой проект содержит 99% подобного мусора, кроме самых мелких — для них ещё всё впереди.
В этом случае можно достичь большей оптимизации — просто удалив воду. Алгоритм при этом не пострадает, я уверен в этом.saipr
13.11.2018 20:32+1Это безумно большая цифра для программного кода
Чем же эта цифра пугает. 10 миллионов строк. В половине строк по одному символу ({ и }), еще четверть строк (если не больше) — комментарии и т.д.
Посмотрите на код Firefox или что-то в этом духе. А вы говорите "безумно большая цифра".
А вся статья изложена в заголовке:
Как мы перевели 10 миллионов строк кода C++ на стандарт C++14 (а потом и на C++17)
Nest_aka_Swan
14.11.2018 09:49Судя по инфографике — 10 миллионов не так уж и много
www.visualcapitalist.com/millions-lines-of-code
tbl
13.11.2018 21:30-1не хотите слезть со своих бинарных протоколов, зашитых на размер wchar_t, на кросплатформенные (protobuf, например)?
DikSoft
14.11.2018 07:00+1Вопрос от чайника. Правильно ли я понял, что теперь фичи новых Xeon/Core будут наконец задействованы? Или флаги компиляции так и остались на «Pentium-4»?
gecube
14.11.2018 09:08Да, кстати, интересный вопрос.
Используются ли дополнительные инструкции процессора в коде, или вся надежда на компилятор, что он верно сам увидит и соптимизирует.
PeterG Автор
14.11.2018 09:55+1К сожалению, мы не можем так просто задействовать фичи новых процессоров у себя в платформе. Некоторое время назад мы пытались банально включить поддержку SSE2 при компиляции 32-битной платформы (в x64 процессорах она уже есть по умолчанию) и сразу получили несколько проблем от внедренцев, т.к. у клиентов до сих пор используются компьютеры, не поддерживающие SSE2.
DikSoft
14.11.2018 10:02+1Печально. Так и будем гоняться по «помойкам» за старыми Xeon На 3.2 ГГц для серверов 1С?
Вариант выпуска нескольких наборов бинарников, условно «под старые процессоры» / «под новые процессоры» хотя бы для Windows платформы не рассматривался?PeterG Автор
14.11.2018 10:37Речь шла о клиентских компьютерах и, соответственно, процессорах. С серверными такой проблемы нет.
По поводу двух редакций — сейчас фактически так и есть, 32-битная платформа для старого железа и ОС, 64-битная платформа — для современных. В том числе для этого мы сделали 64-битный клиент и Конфигуратор.DikSoft
14.11.2018 13:39+1Речь шла о клиентских компьютерах и, соответственно, процессорах. С серверными такой проблемы нет.
— с какого момента с серверными бинарниками нет проблемы, простите?
Если приходится выискивать древние высокочастотные Xeon для того, чтобы оно быстрее работало, а новые не дают прироста скорости от слова совсем.
Серверные бинарники компилируются и оптимизируются под какую версию CPU сейчас?PeterG Автор
14.11.2018 16:04+1У нас нет разделения на серверные бинарники и не серверные. Есть разделение на 32-битные и 64-битные.
Высокая частота и новые инструкции в процессорах не должны коррелировать.
64-битные бинарники собираются с generic x64 инструкциями, включающими в себя, например, sse2 и cmov. AVX не используется, да и мест в платформе таких практически нет, где бы от них был явный выигрыш.gecube
14.11.2018 18:32+1Проблема в том, что новые ядра, в целом, более низкочастотные. Поэтому и приходится искать старые сервера. Тогда ещё не думали об энергоэффективности.
DikSoft
14.11.2018 19:22+1Вот именно!
И вот, что странно. На новых Xeon те же приложения IIS почему-то работают заметно быстрее, а вот 1С — нет. Даже медленнее.
Нет оптимизации или «специфика вычислений» сказывается?gecube
14.11.2018 20:30IIS или не cpu bound, или хорошо параллелится (а тренд на увеличение количества ядер), или сказывается бОльший кэш у новых процов.
А 1С, видимо, чисто упирается в производительность ядра (а она в прямой зависимости от частоты).DikSoft
15.11.2018 10:12..1С, видимо, чисто упирается в производительность ядра (а она в прямой зависимости от частоты).
— и я о том, же.
Т.е. это всё же неоптимальный код или неоптимальная компилляция?
gecube
14.11.2018 10:42+1я не вижу проблемы сделать при старте платформы определение списка поддерживаемых инструкций и выбирать нужную ветку программы. Так делает любой профессиональный пакет типа Photoshop/autocad. Либо действительно тащить разные бинари и запускать нужный.
GorodokVVV
14.11.2018 09:51У нас был свой класс для строк, т.к. у нас в силу специфики нашего софта строковые операции используются очень широко и для нас это критично
и при этом нет нормальной возможности использовать регулярки…PeterG Автор
14.11.2018 10:35+1Проблемы в проекте начинаются после слов программиста «О! Я знаю, как сделать это на регулярных выражениях!» (ц)
Ну а если серьезно — мы периодически возвращаемся к этому вопросу, но окончательного решения пока так и не приняли. Регулярные выражения — это «веревка достаточной длины чтобы выстрелить себе в ногу». Введение ее в платформу, развитие и поддержка — очень серьезная задача, влекущая за собой, помимо вложения в нее ресурсов, как плюсы, так и минусы.
Чего будет больше — вопрос очень непростой.GorodokVVV
14.11.2018 11:01Я прекрасно осознаю, что некоторым программистам нельзя давать в руки спички, а не то что допускать к клавиатуре. Но грести всех под одну гребенку и лишать мощного и гибкого инструмента — это тоже перебор. Поддержка регулярных выражений имеется в каждом уважающем себя языке и мир из-за этого еще не рухнул (вне зависимости от уровня подготовки пишущих на них программистов).
А ресурсы… Я не C++ программист, но думаю задействовать стандартную библиотеку особого труда не составит.PeterG Автор
14.11.2018 15:42задействовать стандартную библиотеку особого труда не составит.
А какую считать стандартной?
Далее, после выбора стандарта, надо документировать, обучать, поддерживать работу на разных ОС и т.д. и т.п.
Т.е. все это — весьма серьезная активность. Плюсы реализации которой, как я уже говорил, неочевидны. А не просто задействовать стандартную библиотеку.
odiemius
14.11.2018 09:51А вот Вы не пробовали потом свои наработки оптимизайций по строкам отправить обратно для включения в boost, stl и иже с ними? Чтоб не только в будущем можно было меньше своих «костылей» лелеять внутри проекта, но и чтоб другие тоже могли воспользоваться?
PeterG Автор
14.11.2018 10:05Нам кажется, в этом нет особого смысла.
Для решения generic задач стандартная строка вполне подходит.
Для решения задач частных, по моему опыту, каждый большой проект пишет строку для себя, под свои потребности и специфику, либо с нуля, либо беря за основу ту же Facebook-строку из folly например.
Т.е. польза для комьюнити от вливания нашей строки в стандарт будет, мягко говоря, спорной — наша строка хороша для наших задач, и не факт, что оптимально подойдет для других проектов.
Классов строк в open-source библиотеках немало (и в стандарт они не вошли!), и добавление нашей реализации ничего нового не привнесет.
cyberzx23
14.11.2018 10:43Проблема в том, что далеко не всем нужны оптимизации SSO и Copy-On-Write. Иногда от них больше вреда, чем пользы. Да и семантика типа сильно меняется.
F0iL
14.11.2018 11:03Copy-on-write раньше был в STL у GCC, например, но потом его оттуда выпилили, т.к. такая реализация противоречит стандарту языка, поскольку в определенных случаях инвалидирует итераторы/ссылки, что как раз именно для этих случаев явно запрещено стандартом :)
Например, в стадарте C++ в пункте 21.4.1 p6 написано:
...invalidation of iterators/references is only allowed for
а неконстантный оператор [] для COW-строки вызывает операцию копирования и как раз инвалидирует итераторы.
— as an argument to any standard library function taking a reference to non-const basic_string as an argument.
— Calling non-const member functions, except operator[], at, front, back, begin, rbegin, end, and rend.
В современных плюсах для экономии ресурсов и избегания лишнего копирования строк рекомендуют использовать std::string_view. Но и подход к работе с ними, соответственно, меняется.
SERG-666
14.11.2018 11:21+1Уважаемый PeterG, Есть два вопроса.
1. В связи с переходом на стандарт C++17 в платформе 14 планируется ли нативная поддержка регулярных выражений?
2. Планируется ли развитие Механизма анализа данных в сторону ML (machine learning)?
Прокомментируйте пожалуйста, если это не секрет.PeterG Автор
14.11.2018 11:221. В связи с переходом на стандарт C++17 в платформе 14 планируется ли нативная поддержка регулярных выражений?
Пока не планируется.
2. Планируется ли развитие Механизма анализа данных в сторону ML (machine learning)?
Прокомментируйте пожалуйста, если это не секрет.
Секрет :)Neikist
14.11.2018 12:06В смысле секрет? Объявлялось же недавно что планируется добавить возможности работы с машинным обучением. Вроде уже где то даже обкатывается.
PeterG Автор
14.11.2018 12:53Объявлялось же недавно что планируется добавить возможности работы с машинным обучением. Вроде уже где то даже обкатывается.
Хм, а ссылку можно?Neikist
14.11.2018 13:09Кажется это было в докладе на ERP форуме
«Фирма „1С“. Состояние дел, стратегия и развитие корпоративного направления» Нуралиев Борис, директор, «1С»
но запись трансляции целиком я почему то не смог найти, хотя смотрел интересующие меня вещи в ней, а по ссылке почему то записи именно этого доклада нет.PeterG Автор
14.11.2018 15:20А, понял.
Детали реализации разгласить пока не можем, к сожалению.
А с ML работаем, конечно, куда сейчас без него.
fishca
14.11.2018 12:29Тесты после перехода показали проседание производительности (местами до 20-30%) и увеличение потребляемой памяти (до 10-15%) по сравнению со старой версией кода. Это было, в частности, связано с неоптимальной работой стандартных строк. Поэтому строку нам опять пришлось использовать свою, слегка доработанную.
Из написанного не до конца понятно производительность вернулась на прежний уровень или нет после изменений?
xmarkers
14.11.2018 12:56Не совсем касается статьи, но некоторые пожелания по развитию платформы:
1) Сделайте в конфигураторе, возможность группировать те же общие модули (хотя бы их) либо по подсистемам (про отбор по подсистемам я в курсе), либо (что лучше) вообще сделать возможность создания произвольных групп. Например создать группу «Работа с подключаемым оборудованием» или «Мои модули», а то в современных конфигурациях написанных на базе БСП и БПО, такое большое количество модулей, что становится тяжело с ними работать. При этом можно (и наверное даже нужно), чтобы эта иерархия была прозрачная для кода (тогда ничего не придется существенно изменять).
2) Для динамических списков, не хватает возможности выборки временной таблицы, бывает что есть достаточно большой объём тяжелой «статичной» информации, которую и дорого считывать постоянно, да и нет особой необходимости. Я понимаю, что это вступает в конфликт с «Динамическим считыванием», но можно же как-то разделить части запроса, какие считываются один раз, а какие данные обновляются динамически?
3) При работе с внешними источниками данных, не хватает возможности создания произвольных запросов к базе на её диалекте. Бывают ситуации, когда оптимально написать прямой запрос к базе, имея все возможности базы данных, а не только те, которые предоставляет 1С. Да, есть функции, но опять же, их нельзя создать средствами ВИД.
4) В некоторых ситуациях, в целях оптимизации дорогого вызова сервера (особенно на медленных сетях), очень не хватает событий вроде «ПередВызовомСервераНаКлиенте», «ПриВызовеСервераСКлиента», «ПередЗавершениемВызоваСервераСКлиента», «ПриЗавершенииВызоваСервераНаКлиенте». Ибо есть необходимость, каких-то периодических обращений к серверу, для получения «команд», информации и пр., при этом нет «срочности» получения информации, было бы удобно, перед вызовом сервера (как из кода, так и внутренние потребности 1С, например обновление динамического списка и пр.), в событии «ПередВызовомСервераНаКлиенте» сформировать некую произвольную структуру необходимой информации, в событии «ПриВызовеСервераСКлиента» получать её с клиента и обрабатывать ну и в событии «ПриЗавершенииВызоваСервераНаКлиенте» получать запрошенные данные с сервера. Это бы позволило минимизировать обмен с сервером и формировать некие «пакеты» на запрос к серверу. А так несколько обработчиков которым периодически нужно вызывать сервер, в разных местах + потребность платформы в вызовах сервера = Излишние обращения к серверу, которые на медленных сетях порой очень дорогие! (интернет же не везде хороший)
5) Ну и упоминавшаяся уже в комментариях, необходимость в регулярных выражениях, ибо технически, платформа умеет с ними работать (проверка типа в XDTO), но прямого доступа из кода нет. Лично для меня, это уже вторично, в некоторых местах, использую хак проверки через XDTO, хотя этот способ как мне кажется, достаточно дорог в отличии от нативной поддержки.
6) Возможность расчета контрольной суммы (Хеширование) на клиенте. Как-то не логично передавать 5 гиговый файл на сервер, только для того чтобы узнать его контрольную сумму, в данный момент приходится использовать консольные программы для этого.
7) Сделайте возможность deflate упаковки строк, сама платформа активно использует этот алгоритм в тех или иных местах, однако, разработчику данный механизм не доступен (если не рассматривать хаки через ZIP файл)
Что-то было ещё, но уже забыл. В целом мне очень нравится курс, который вы взяли начиная с 8.3.9, добавляя всё больше и больше, очень вкусных возможностей, в том числе которые «казалось бы» не нужны в «бухгалтерской» программе.
Спасибо!
DeuterideLitium6
14.11.2018 13:20А 10 мегастрок, это сколько мегабайт исходников?
А то я в последнее время приобрёл привычку сжимать исходник, чтобы колёсико мышки меньше изнашивалось.
Раньше делал так:
if(condition) { code } else { code }
А теперь делаю так:
if(condition){ code }else{ code }PeterG Автор
14.11.2018 16:10+1А 10 мегастрок, это сколько мегабайт исходников?
> 600 Мб
А то я в последнее время приобрёл привычку сжимать исходник
Ну тут дело вкуса.
Что до меня — я готов увеличить размер исходника, но получить лучше читаемый код, мне открывающие фигурные скобки на новой строке глаз радуют :)
alexey-lustin
14.11.2018 13:25многие вещи элегантней, проще и надежней, упрощал поддержку и сопровождение кода
Спрошу публично. Учитывая что в заголовке заявлена указанная цель перехода, можно ли сказать что ситуация с 8.4 редакцией улучшится? В публикации и в комментариях все ссылаются на 8.3.XXXX.
На последнем Хайлоаде++ в целом и у многих клиентов все чаще мы видим кластера Kubernetes, мы вынуждены использовать собственные образа docker с 8.3 на борту, которая не сильно для таких развертываний предназначена. Я уже не говорю про OpenShift — там идет еще тяжелей.
justhabrauser
14.11.2018 14:17-3А я думаю — почему же это после обновления платформы до самой свежей всё стало жутко тормозить?
А вишь оно как… П == Прогресс.
PS. нагрузочные тесты? Не, не слышал.DeuterideLitium6
14.11.2018 14:32+1А во обще странно, почему тормозит. Я недавно тестировал компиляторы VS C++ 2010 и VS C++ 2017, да к новый компилятор генерирует более оптимальный код, 5-10% можно получить быстродействия, и это простой перекомпиляцией. Ну а если вдруг проект стал тормозить значит, значит к проекту прилипла что-то тормозящие, в смысле библиотека.
F0iL
14.11.2018 16:36Ну а если вдруг проект стал тормозить значит, значит к проекту прилипла что-то тормозящие, в смысле библиотека.
Либо система начала тормозить из-за чего-то совершенно другого, а не из-за перевода на другой стандарт языка или замены компилятора.
alexey-lustin
14.11.2018 22:54+1Как у вас так получается? До какой самой свежей вы обновились — конкретную версию пожалуйста озвучьте. Версию PostgreSQL также желательно высказать. Может вы взяли ванильную неофициальную и вручную попытались патчи наложить. Также платформа 1С не работает в вакууме — вопрос в конфигурации которую вы используете. У любой конфигурации есть режим совместимости, соответственно исходя из режима совместимости конфигурации вы можете получить хоть какое-то представление о тормозах и их причинах. Если они конечно не кроются в коде написанным приходящим программистом 1С — который внезапно что-то намудрил с 256-тью таблицами.
justhabrauser
15.11.2018 22:57-1Легко и непринужденно:
* берем крайнюю версию платформы (8.3.13.1513, если склероз не изменяет)
* берем крайнюю версию Бухгалтерии (3.0.65.сколькототам)
* запускаем 10 штук баз одновременно (файловых, на не самом поганом немецком хостинге, на честно купленной Windows Server 2008 R2)
* сидим и курим ЧАС, пока оно взлетит
Загрузка процессора (всех четырех ядер) — 5-10%
Никаких тюнингов и выпендриваний — всё by default.
Вот как так вот?
Я такое кунг-фу не умею.
Чтобы так убить работу — я не умею.
PS. TPC говорит, что лучше, чем на этом сервере — технически существовать не может.
Шутка, конечно, но тем не менее.
ssnikita
16.11.2018 11:52PeterG Добрый день,
можете пожалуйста рассказать какой % кода написан на C++, а какой на других языках (без учета веб клиента, сервера взаимодейстивия, EDT и прочих явно написанных на других языках элементов инфраструктуры 1С). Надеюсь это не какая-то тайна, можно очень примерно (90 на 10, 80 на 20 и тд). Особенно интересно сколько места в платформе занимает Java и есть ли она там вообще. Если всё же Java там есть было бы супер услышать несколько примеров какие блоки на ней реализованы. Спасибо!PeterG Автор
16.11.2018 11:58Добрый день!
Я сейчас не в офисе, с разработчиками проконсультироваться не могу. Но, насколько помню, если отбросить все вами перечисленное — С++ занимает 97%-99%. Несколько визуальных контролов (точно помню про планировщик и форматированный документ) написаны с применением JavaScript.
Java, насколько помню, применяется только в EDT и Сервере Взаимодействия. Возможно еще где-то в утилитах администрирования, но 100% не уверен.
netricks
А какой смысл в переводе всего кода проекта на новый стандарт?
APXEOLOG
Начиная от использования новых возможностей языка, заканчивая нежеланием разработчиков всю жизнь возиться с языком (и костылями) двадцатилетней давности
pavelkolodin
Атом углерода вообще устроен по принципам чёрт знает скольки летней давности, но вы же не пытаетесь слезть с углеродной жизни.
APXEOLOG
Ну так вариантов-то нету, апдейтов миллиарды лет не было
willyd
Иногда мержится в гелий.
domix32
А ты ж поди разбери весь этот легаси.
bolk
Уж несколько десятилетий медленно, но упорно ползём на кремний.
0xd34df00d
Еду, вполне себе сделанную из того же углерода, вы, однако, не захотите есть после истечения срока годности.
amarao
Атом углерода работает на bleeding edge квантовой физики. Как только выпускают обновление квантовой физики, он автоматически на неё переходит.
После того, как релизнут теорию струн, он автоматически спортируется на теорию струн (это show-stopper для теории струн).
gibdd229
сначала бы разобраться, что такое время…
по идее нету там никаких миллиардов
Suvitruf
В процессе переписывания можно кучу багов наплодить. Не всё так однозначно, всё же.
resetme
А можно ещё и отловить много старых и пофиксить.