Статья не бесполезная, многие кто занимается переходом с УПП в ERP сталкиваются с решением подобной задачи, но без ссылок на инструменты и расширения, практического смысла не много.
Есть вопрос по разделам:
"4. Автоматизация заполнения объектов"
"5. Гибкие права доступа к объектам"
Как они относятся к теме статьи? Не все получилось сделать ролями и часть делали с помощью "5. Гибкие права доступа к объектам" ? В УПП был аналогичный функционал?
Плюс не понятно как при маппинге пользователей УПП на типовые профили решалась проблема с тем что в типовом профиле есть лишние права.
Т.е. понятна ситуация когда есть типовой профиль и к нему нужно добавить дополнительные права, делаем опциональный профиль и таким образом получаем требуемую функциональность. Но если в типовом профиле есть лишние права то такой вариант не сработает.
Вот тоже посмотрел тесты, хотел написать то же самое. Xeon 2673v3 (12 ядер, 3.3 ГГц) за 6500 рублей + Atermiter 4000р + 32 RAM (4 плашки по 8 гб 2133) за 6500.
Итого 17000р, дают практически тот же результат по задержке: 71,2, и незначительно меньше по скорости: 62850.
При этом с DDR5 только модули памяти стоят 30 000р, что на 460% дороже а быстрее на 30%.
И не особо понятно почему в потребительских сегментах не делать 4 канала. Понятно что больше дорожек и выводов нужно делать, и немного больше кристал процессора получится, но не руками же это делают, а "роботу" не так и принципиально сколько дорожек разводить. Не так дорого это выходит.
Доходит до смешного, нам предлагают 12 ядерные i7 с 25 мб кэша и двумя двумя контроллерами памяти. Даже если есть задачи которые способны нагрузить 12 ядер, то как их прокормить?
Вот Apple молодцы сделелали 4 канала DDR4 (там 2 но 128 битных что как раз равно 4м 64 битных в Intel/AMD) и у них на выходе M1 Pro дает 200 ГБ/с, а M1 Max - 400 ГБ/с.
Что такое 85 ГБ/с на топовой DDR5 памяти в разгоне против даже 200 ГБ/с у M1 Pro и уж темболее 400 ГБ/с у M1 Max?
На мой взгляд ГИС ЖКХ обычная система консолидирующая данные не плохая и не хорошая. А 60% проблем свзяано с требованиями по подписи и шифрованию протоколов если почитать чат разработчиков интеграций, то там основные проблемы с сертификатами, и с тем что временами сервис не работает.
Плюс на мой взгляд очень сильно намудрили с квитированием, бесполезная по сути операция (для абонента) и очень сложная для РСО и УК.
Остальные 30% проблем связаны с тем что у многих РСО и УК просто нет ИТ специалистов что бы решать проблемы работы с ГИС ЖКХ, все идет через несколько посредников, или вообще EXCEL отсюда и проблемы с непрогруженными показаниями.
Хотели бы навести порядок, сделали бы единный билинг для ФЛ на всю страну. Если откинуть различные извращения, стандартизировать и упростить правила расчет то система будет достаточно простая. И многие РСО с удовольствием бы платили за использование такой системы в облаке.
Да, признаю со свалкой погорячился, скажем так у меня есть внутреннее убеждение что 28 нм могут продать, а вот 12 нм просто прийти и купить не получится. Даже за большие деньги.
На мой взгляд доверять нельзя никому и особенно нельзя доверять себе, потому что как показывает мой опыт нет врага страшнее чем ты сам.
Закладкой может воспользоваться тот кто её заложил, это плохо но тем не менее гораздо хуже если в процессоре / архитектуре есть уязвимости которые может найти кто угодно. И такие ошибки и уязвимости есть всегда как и в любой программе, хорошие программы отличаются от плохих в первую очередь степенью тестирования и привлеченных ресурсов. А полноценное тестирование / исследование может потребовать ресурсов больше чем разработка. Это такая же школа как и разработка процессоров.
И по факту имеем пониженную вероятность закладок в процессор (на фабрике) и повышенную вероятность наличия уязвимостей (т.к. просто нет ресурсов на полное тестирование).
все эти танцы - только для того, чтобы выпускать эти процессоры под своим брендом, как сейчас модно.
На мой взгляд это нужно в первую очередь для развития. Можно вспомнить китайский MediaTek они начинали без амбиции на мировое господство с MT6218B в 2003, а сейчас выпускают Dimensity 1200 который по соотношению цена/железо рвет флагманский qualcomm, но по софту конечно отстает т.к. за плечами qualcomm стоит google а вот MediaTek справляется своими силами. Но на потребительском уровне это отставание не заметно вообще а вот по цене выгода заметна.
Ребята из MediaTek сделали правильную ставку на ARM и из откровенно ужасных MT6218B которые стояли во всех телефонах NOKLA (с ТВ и антенной) догнали лидеров (qualcomm) и обогнали конкурентов (Exynos). Еще год два и увидим первые сервера на ARM и у MediaTek уже есть все необходимые компетенции для того что бы предложить свои продукты.
Вот только какое развитие у vliw мне не понятно, intel вложились в него, но потом отказались, где кроме DSP он сейчас используется я и не знаю.
Я вообще не уверен что кто угодно может в ASML прийти и купить такой станок даже если у него будут деньги. Слишком ценный это ресурс что бы его за деньги продавать.
Это для нас деньги это мерило всего, но есть предел после которого деньги уже совсем по другому ценятся, и владельцы ASML уже давно далеко ушли от этого предела.
Как не пиши код но DDR3-1600 с 4х канальным контроллером так и останется DDR3-1600 с 4 каналами.
Да можно потратить ресурсы и оптимизировать узкие места, но точно так же можно потратить те же ресурсы на оптимизацию под x86 и получить такой же а то и больший прирост.
Но есть опасения что остальной мир не бросится переписывать библиотеки и JVM под vliw архитектуру, а доля кода тех же разработчиков сбера в общем коде решения не больше 10%.
Мой опыт и здравый смысл говорит о том что подсистема памяти и интерфейсы доступа к данным на внешних накопителях (кстати что у эльбруса, явно же не SATA3?) катастрофически влияют на скорость работы при реальной рабочей нагрузке на сервер. И даже в CPU с DDR4-2400 и 6ю каналами на серверах всё упирается в память, и особенно в случае с JAVA. И всё что можно делать со стороны программиста это как то работать с кэшем (что делать из Java не так то просто).
А в случае с СУБД еще интерфейсы доступа к внешним хранилищам. (сами хранилища выносим за скобки).
Поэтому даже при идеальном раскладе DDR3-1600 c 4 каналами памяти будет на 50% хуже чем DDR4 - 3000 c 6 каналами. И еще учитывая что везде скромно умалчивается о успехах в реализации межъядерного и межпроцессорного взаимодействия, можно предположить что в Эльбрусе это так же реализовано похуже чем на современных x86 и серверных чипсетах.
Тема тестирования серверных процессоров очень скользкая, так как работа сервера полностью отличается от работы игрового или рабочего ПК и в реальной работе на первый план выходят такие характеристики как Частота системной шины, Кол-во соединений QPI, размер и организация доступа к кэш памяти и.т.п. Это для десктопа где сидит один юзер и работает 5 программ кэш в 30 мб решает 90% доступа к памяти.
А вот сервер который обрабатывает 10 000 запросов в секунду свои 30 Мб выедает очень быстро, и дальше какой бы мощный процессор не был все его ядра стоят и ждут данных из памяти (показывая загрузку в 100% но ничего не делая). Не зря в последних моделях процессоров интел уже идет практически отдельный микроконтроллер который занимается анализом и предсказанием, частично конечно что бы загрузить ядра работой, но главная задача это упреждающее чтение в кэш.
Конечно у эльбруса с его 1.3 ггц не такой большой голод данных, но опять же там и инструкции по жирнее. Конечно было бы круто если бы сбер опубликовал результаты своих тестов.
Сделать процессор сложно, сделать серверный процессор сложно в квадрате, плюс серверный процессор существует не в вакууме ему ещё нужна соответствующая обвязка от которой так же много зависит (особенно в многопроцессорных системах).
Я в новостях часто читаю что наш процессор поможет нам обезопасить страну, от закладок в процессоре, от санкций и.т.п.
Но на мой взгляд:
1. Если дойдет до запрета продажи нам процессоров то наверное запретят продавать и материнские платы и жесткие диски и заказы на изготовление тоже размещать не дадут. Как то слабо вериться в сценарий когда запретят только процессоры.
2. Закладки (в процессорах) это конечно хорошо, но как показала практика meltdown и spectre и без закладок возможно получать доступ к памяти ядра системы. И на мой взгляд ещё не известно что хуже закладки которыми могут пользоваться только те кто их заложил, или подобные уязвимости доступные гораздо более широкому кругу лиц. И если уж Intel с их многолетним опытом допускают такие ошибки то какова вероятность наличия таких ошибок в новых архитектурах?
Вообще интересно было бы почитать мнение экспертов об устойчивости архитектуры эльбрусов к подобным проблемам и вообще к уязвимостям. На уровне моего понимания того как устроены процессоры использование длинных слов открывает больше векторов для атаки, но это скорее догадки чем предположение.
Если честно жаль что наш ЦП не на арм, у меня есть стойкое впечатление что мы сейчас на пороге (а может уже и дальше) революции и переходе всего мира ИТ на ARM, и тут можно было бы выстрелить, а пока всё что я понял и прочитал про архитектуру Эльбруса больше похоже на выстрел в ногу.
Теория заговора
Если погрузиться в теорию заговора, то можно предположить, что специалисты по ARM нужны всему миру, и что если делать ставку на ARM придется конкурировать со всем миром за специалистов, а если специалист заточен на vliw то вероятность что его куда сманят значительно уменьшается. Что то похожее у нас с 1С, ты можешь быть крутым спецом по 1С но за пределами 1С ты не интересен.
Зачем Китаю продавать нам оборудование и знание, если можно значительно дороже продавать нам микросхемы. Я конечно не эксперт в глобальной экономике, но на мой обывательский взгляд, в таких масштабах деньги это просто бумага, а в наше время уже давно не бумага.
Какая выгода китаю от появления конкурентов на рынке?
Вопрос ещё кто нам продаст эти технологии. На мой взгляд не очень умно продавать станки по производству денег из песка. Да наверное 28нм ещё можно продать, не выкидывать же на свалку. Но более современные... сильно сомневаюсь.
И дело даже не в санкциях, просто в чём смысл плодить конкурентов?
Все так и есть, 1С это действительно доступно и всерьез.
Единственное в чем я с вами не согласен так это в масштабе до 1000 человек. Проблем не будет с типовыми решениям до 200-300 пользователей.
Дальше уже начинаются сложности, нужны эксперты которые за этим будут следить. Но даже для 300 человек сложно найти не допиленную типовую, и вот дальше у платформы появляются проблемы:
Запредельная сложность крупных конфигураций (Отсутствия ООП, Типизации, Какой либо структуры хранения модулей)
Сложность прикладной части (это отдельная боль).
Отвратительная производительность платформы (тут ниже есть мой пример сравнения с java)
Игнорирование прогресса в разработке СУБД начиная с 92 года. (Газпром вынужден тратить миллиард на сервера СУБД под 1С потому что у 1С есть файловый вариант для ларька который дережит Арсен, и все возможности платформы по работе с СУБД ограниченны этим вариантом).
Жесткий монолит (тут без коментариев, достаточно посмотреть как реализована бесшовная интеграция с документооборотом, я когда смотрю всегда восхищаюсь тем сколько сил и труда было вложено в то что в WEB разработке идет бесплатно).
Сжатые сроки + бизнес на первом месте, а отдел автоматизации где то между завхозом и гаражом, прибыли не приносит, сидят там одни дармоеды и вот это все...)
Причем эти пункты нужно не складывать а перемножать. И
Возьмите любой ORM или тем более современный JS framework там 30% разработчиков не то что не задумываются о том как это реализовано а даже не понимают что там вообще что то под капотом), особенно это касается Frontend.
На самом деле то что 1С позволяет такое писать не проблема 1С, любая ORM с ленивым чтением будет делать то же самое.
Писать так или нет тоже зависит от задачи, ну и для справедливости прям так никто не пишет, это большая редкость. Чаще просто получают через 1-2 точки и это нормально если ты дальше что то делаешь с этим объектом и если у тебя не HiLoad блок а что то что выполняется раз в месяц.
И чаще всего в разыменовываемых объектах не лежат огромные хранилища значений.
При этом СУБД нет особой разницы прочитать один реквизит или прочитать всю строку. Поэтому я бы не стал в большинстве случаев на это обращать внимание.
Они не нужны там где ты можешь выделить отдельные классы с методами, разместить их в соответствующих каталогах и.т.п. В 1С когда у тебя в одном модуле размещены 95 процедур и 129 функций при этом все они так или иначе вызывают процедуры и функции из других модулей с таким же названием но с другой инструкцией (ПовтИсп, ВызовСервера и.т.п.) комментарии с описанием что это, какие у него параметры жизненно необходимы.
Такое есть везде. Проблема говнокода в 1С встречается чаще из за более низкого порога и сжатых сроков т.к. 80% разработки 1С это разработка по часам. Это примерно как ожидать от продажной женщины за 1500р в час такого же отношения и внимания как от жены.
Но на самом деле проблема такого говнокода это все же проблема того кто пишет и команды (правда в 1С опять же 70% работает без команды). Но никак не платформы и не языка.
Это не java как минимум потому что нет ООП что делает поддержку крупных проектов практически не возможной, и местами героической.
Вторым важным отличием является отсутствие типизации, компилятор вам редко когда что то может подсказать или как то иначе помочь. Надежда только на себя и свою память.
Представьте java без ООП (У вас есть только процедуры и функции) в котором перемешаны SQL запросы, всё это в 350 модулях в одном каталоге (иерархия хранения модулей не поддерживается) каждый модуль от 1000 до 20 000 строк (иначе модулей было бы не 350), эти модули сильно между собой зависимы и по факту просто содержат процедуры и функции, нет интерфейсов, контрактов, каких либо других описаний, ты просто должен всё это помнить сам.
Есть пара стандартов на бумаге где и что размещать но всё это абсолютно не поддерживается средой разработки и языком, иногда складывается впечатление что платформу разрабатывает не крупнейшая в РФ корпорация а просто open source сообщество.
С другой стороны понятно что бейсик (а по факту 1С это и есть бейсик только с фреймворком в виде платформы) не предназначен для всего того куда сейчас платформу продвигают.
1С отличная система с низким порогом входа пока у вас небольшая конфигурация (что редко) или пока вы правите какие то редкие куски большой конфигурации или делаете отчеты/обработки (чем занимается 90% франчей).
В Java перебравшись через порог новичок идет по ступенькам с перилами (ООП, IDE, Code Review, Патерны, Тесты). В 1С за порогом тебя ждет плато на горизонте которого находится отвесная стена, по которой нужно карабкаться дальше.
На мой взгляд людям которые создали ERP, БСП 3.0 при жизни нужно памятник ставить, настолько титанический труд. Страшно подумать каких бы высот они достигли имея дело с современными промышленными языками.
По факту всё что во всем мире является плохим стилем, в 1С норма по определению. Да у 1С есть стандарты разработки, но они на "бумаге" а не в IDE и следовать им это значит ещё сильнее нагрузить свой мозг борьбой с 1С а не решением проблем.
Да и быстродействие 1С это грусть печаль, если JVM оптимизируют всем миром, то виртуальная машина 1С написана в соответствии с первым постулатом "Главное, чтобы работало".
Для примера: Массив из 33 000 000 машинных номеров.
1С:
Формирование массива: 901 156 мс (Цикл + генератор случайных чисел+массив.Добавить(Значение)).
Поиск в массиве не существующего элемента средствами платформы: 19164мс. (Массив.Найти(Значение))
Занимает 2.7 гб RAM.
Java (такой же код на той же системе):
Формирование массива: 52651.3931 мс
Поиск в массиве не существующего элемента : 190.6821 мс (arr.contains(Value))
В памяти точно не помню, по моему около 300 мб.
Вообще там такой багаж проблем (стоимость и вообще необходимость лицензий, ORM ограниченная только урезанным Select которая мощнейшие СУБД с их возможностями использует как замену DBF файлов).
Отдельная боль это гигантомания и монолитизация всего, базы по 2-3 TB на крупных проектах это норма. Когда спрашиваешь у разработчиков PG совета как бы заставить этого монстра работать, в ответ всегда получаешь:
- "Зачем вам такая база?" Разбейте на 10-20 поменьше, выделите сервисы, какие то данные перекиньте в архив и.т.п).
После упоминания что это 1С обычно разговор заканчивается, потому что говорить тут просто не о чем.
Альтернативы нет, так как в крупном ent нет 1С, в лучшем случае прикладные решения (бух,зуп) делать им конкурентов долго, дорого а выхлоп только за счет массовости, а это своя сеть продаж и.т.п. Плюс с локом на РФ. Кому это счастье нужно?
Посмотрите на современный мир, не кто не хочет продавать коробку, все продают сервисы, в для этого 1С не подходит в принципе. Да фреш прикрутили но это для малых ИП и в целом костыль (так как монолит).
Если речь о платформе на которой можно быстро выдать продукт, так есть масса фреймворков, может чуть сложнее порог входа, но это и к лучшему, плюс за счет ООП фреймворки на порядок гибче.
В общем если коротко то рынок который заняла 1С не интересен т.к. уже устарел там нет перспектив, поэтому и желающих нет.
В том и смысл что frontend не должен знать SQL, но должен в совершенстве знать свою часть, так же и backed и DBA и архитекторы и дизайнеры, каждый занимается своей работой.
И только в 1С ты должен и интерфейсы проектировать и предметную область знать, и в SQL разбираться + чемодан сюрпризов самой платформы + управляемые блокировки.
А ЗП у тебя будет по низу ИТ рынка.
2) 1C как бэкенд — прекрасно заходит infostart.ru/1c/articles/1237578. Боитесь проблем с масштабированием — есть OneScript
Как OneScript помогает решать проблемы с лицензиями и главное извращенной архитектурой БД?
4) Научитесь делать нормальные интерфейсы в т.ч. в 1С решениях event.infostart.ru/2021/agenda/#item1291409
Что бы делать хотя бы часть из описанного в agenda нужно быть не слабым JS разработчиком. Я как то просил знакомого фулстек помочь вытянуть мне данные из WEB клиента (нужно было интегрироваться имея доступ только к WEB клиенту). Он провозился несколько дней что то смог сделать что то нет, и говорил о WEB интерфейсе 1С примерно теми же словами что другой знакомый DBA использует когда говорит о том как 1С с СУБД работает.
5) Освойте уже proxy и injection — меняйте 1С-ные CSS на свой лад github.com/ovcharenko-di/crserver-filter
Может быть освоить просто JS + React (vue) и делать сразу нормальные MVC интерфейсы?
6) Пройдите всю цепочку Дизайн — прототип — user-flow — вёрстка — Бэк — фронт — адаптив — mobile для того чтобы понять как много для вас делает движок 1С.
Все выше перечисленное делается разными людьми. Это разработчики 1С делают все выше описанное за 6х человек, а ЗП получают как 70% от одного из этих 6.
А потом хвалятся какая 1С дешёвая и популярная, конечно дешёвая, за счет вашей ЗП и нагрузки, дешевая.
И нужно определиться у нас тут low code или js + css + one script + faas.
Статья не бесполезная, многие кто занимается переходом с УПП в ERP сталкиваются с решением подобной задачи, но без ссылок на инструменты и расширения, практического смысла не много.
Есть вопрос по разделам:
"4. Автоматизация заполнения объектов"
"5. Гибкие права доступа к объектам"
Как они относятся к теме статьи? Не все получилось сделать ролями и часть делали с помощью "5. Гибкие права доступа к объектам" ? В УПП был аналогичный функционал?
Плюс не понятно как при маппинге пользователей УПП на типовые профили решалась проблема с тем что в типовом профиле есть лишние права.
Т.е. понятна ситуация когда есть типовой профиль и к нему нужно добавить дополнительные права, делаем опциональный профиль и таким образом получаем требуемую функциональность. Но если в типовом профиле есть лишние права то такой вариант не сработает.
Неужели у вас не было таких вариантов?
Вот тоже посмотрел тесты, хотел написать то же самое. Xeon 2673v3 (12 ядер, 3.3 ГГц) за 6500 рублей + Atermiter 4000р + 32 RAM (4 плашки по 8 гб 2133) за 6500.
Итого 17000р, дают практически тот же результат по задержке: 71,2, и незначительно меньше по скорости: 62850.
При этом с DDR5 только модули памяти стоят 30 000р, что на 460% дороже а быстрее на 30%.
И не особо понятно почему в потребительских сегментах не делать 4 канала. Понятно что больше дорожек и выводов нужно делать, и немного больше кристал процессора получится, но не руками же это делают, а "роботу" не так и принципиально сколько дорожек разводить. Не так дорого это выходит.
Доходит до смешного, нам предлагают 12 ядерные i7 с 25 мб кэша и двумя двумя контроллерами памяти. Даже если есть задачи которые способны нагрузить 12 ядер, то как их прокормить?
Вот Apple молодцы сделелали 4 канала DDR4 (там 2 но 128 битных что как раз равно 4м 64 битных в Intel/AMD) и у них на выходе M1 Pro дает 200 ГБ/с, а M1 Max - 400 ГБ/с.
Что такое 85 ГБ/с на топовой DDR5 памяти в разгоне против даже 200 ГБ/с у M1 Pro и уж темболее 400 ГБ/с у M1 Max?
Да и 30Мб кэша на 8 ядер выглядит куда лучше.
Почему вручную? У Ланита есть API для этого.
На мой взгляд ГИС ЖКХ обычная система консолидирующая данные не плохая и не хорошая. А 60% проблем свзяано с требованиями по подписи и шифрованию протоколов если почитать чат разработчиков интеграций, то там основные проблемы с сертификатами, и с тем что временами сервис не работает.
Плюс на мой взгляд очень сильно намудрили с квитированием, бесполезная по сути операция (для абонента) и очень сложная для РСО и УК.
Остальные 30% проблем связаны с тем что у многих РСО и УК просто нет ИТ специалистов что бы решать проблемы работы с ГИС ЖКХ, все идет через несколько посредников, или вообще EXCEL отсюда и проблемы с непрогруженными показаниями.
Хотели бы навести порядок, сделали бы единный билинг для ФЛ на всю страну. Если откинуть различные извращения, стандартизировать и упростить правила расчет то система будет достаточно простая. И многие РСО с удовольствием бы платили за использование такой системы в облаке.
Это хороший вопрос. Такой же как про лес и нефть.
Это вопросы к нашим (нашим?) людям из правительства. У меня на такие вопросы ответов нет
Да, признаю со свалкой погорячился, скажем так у меня есть внутреннее убеждение что 28 нм могут продать, а вот 12 нм просто прийти и купить не получится. Даже за большие деньги.
На мой взгляд доверять нельзя никому и особенно нельзя доверять себе, потому что как показывает мой опыт нет врага страшнее чем ты сам.
Закладкой может воспользоваться тот кто её заложил, это плохо но тем не менее гораздо хуже если в процессоре / архитектуре есть уязвимости которые может найти кто угодно. И такие ошибки и уязвимости есть всегда как и в любой программе, хорошие программы отличаются от плохих в первую очередь степенью тестирования и привлеченных ресурсов. А полноценное тестирование / исследование может потребовать ресурсов больше чем разработка. Это такая же школа как и разработка процессоров.
И по факту имеем пониженную вероятность закладок в процессор (на фабрике) и повышенную вероятность наличия уязвимостей (т.к. просто нет ресурсов на полное тестирование).
На мой взгляд это нужно в первую очередь для развития. Можно вспомнить китайский MediaTek они начинали без амбиции на мировое господство с MT6218B в 2003, а сейчас выпускают Dimensity 1200 который по соотношению цена/железо рвет флагманский qualcomm, но по софту конечно отстает т.к. за плечами qualcomm стоит google а вот MediaTek справляется своими силами. Но на потребительском уровне это отставание не заметно вообще а вот по цене выгода заметна.
Ребята из MediaTek сделали правильную ставку на ARM и из откровенно ужасных MT6218B которые стояли во всех телефонах NOKLA (с ТВ и антенной) догнали лидеров (qualcomm) и обогнали конкурентов (Exynos). Еще год два и увидим первые сервера на ARM и у MediaTek уже есть все необходимые компетенции для того что бы предложить свои продукты.
Вот только какое развитие у vliw мне не понятно, intel вложились в него, но потом отказались, где кроме DSP он сейчас используется я и не знаю.
Я вообще не уверен что кто угодно может в ASML прийти и купить такой станок даже если у него будут деньги. Слишком ценный это ресурс что бы его за деньги продавать.
Это для нас деньги это мерило всего, но есть предел после которого деньги уже совсем по другому ценятся, и владельцы ASML уже давно далеко ушли от этого предела.
Как не пиши код но DDR3-1600 с 4х канальным контроллером так и останется DDR3-1600 с 4 каналами.
Да можно потратить ресурсы и оптимизировать узкие места, но точно так же можно потратить те же ресурсы на оптимизацию под x86 и получить такой же а то и больший прирост.
Но есть опасения что остальной мир не бросится переписывать библиотеки и JVM под vliw архитектуру, а доля кода тех же разработчиков сбера в общем коде решения не больше 10%.
Мой опыт и здравый смысл говорит о том что подсистема памяти и интерфейсы доступа к данным на внешних накопителях (кстати что у эльбруса, явно же не SATA3?) катастрофически влияют на скорость работы при реальной рабочей нагрузке на сервер. И даже в CPU с DDR4-2400 и 6ю каналами на серверах всё упирается в память, и особенно в случае с JAVA. И всё что можно делать со стороны программиста это как то работать с кэшем (что делать из Java не так то просто).
А в случае с СУБД еще интерфейсы доступа к внешним хранилищам. (сами хранилища выносим за скобки).
Поэтому даже при идеальном раскладе DDR3-1600 c 4 каналами памяти будет на 50% хуже чем DDR4 - 3000 c 6 каналами. И еще учитывая что везде скромно умалчивается о успехах в реализации межъядерного и межпроцессорного взаимодействия, можно предположить что в Эльбрусе это так же реализовано похуже чем на современных x86 и серверных чипсетах.
Тема тестирования серверных процессоров очень скользкая, так как работа сервера полностью отличается от работы игрового или рабочего ПК и в реальной работе на первый план выходят такие характеристики как Частота системной шины, Кол-во соединений QPI, размер и организация доступа к кэш памяти и.т.п. Это для десктопа где сидит один юзер и работает 5 программ кэш в 30 мб решает 90% доступа к памяти.
А вот сервер который обрабатывает 10 000 запросов в секунду свои 30 Мб выедает очень быстро, и дальше какой бы мощный процессор не был все его ядра стоят и ждут данных из памяти (показывая загрузку в 100% но ничего не делая). Не зря в последних моделях процессоров интел уже идет практически отдельный микроконтроллер который занимается анализом и предсказанием, частично конечно что бы загрузить ядра работой, но главная задача это упреждающее чтение в кэш.
Конечно у эльбруса с его 1.3 ггц не такой большой голод данных, но опять же там и инструкции по жирнее. Конечно было бы круто если бы сбер опубликовал результаты своих тестов.
Сделать процессор сложно, сделать серверный процессор сложно в квадрате, плюс серверный процессор существует не в вакууме ему ещё нужна соответствующая обвязка от которой так же много зависит (особенно в многопроцессорных системах).
Я в новостях часто читаю что наш процессор поможет нам обезопасить страну, от закладок в процессоре, от санкций и.т.п.
Но на мой взгляд:
1. Если дойдет до запрета продажи нам процессоров то наверное запретят продавать и материнские платы и жесткие диски и заказы на изготовление тоже размещать не дадут. Как то слабо вериться в сценарий когда запретят только процессоры.
2. Закладки (в процессорах) это конечно хорошо, но как показала практика meltdown и spectre и без закладок возможно получать доступ к памяти ядра системы. И на мой взгляд ещё не известно что хуже закладки которыми могут пользоваться только те кто их заложил, или подобные уязвимости доступные гораздо более широкому кругу лиц. И если уж Intel с их многолетним опытом допускают такие ошибки то какова вероятность наличия таких ошибок в новых архитектурах?
Вообще интересно было бы почитать мнение экспертов об устойчивости архитектуры эльбрусов к подобным проблемам и вообще к уязвимостям.
На уровне моего понимания того как устроены процессоры использование длинных слов открывает больше векторов для атаки, но это скорее догадки чем предположение.
Если честно жаль что наш ЦП не на арм, у меня есть стойкое впечатление что мы сейчас на пороге (а может уже и дальше) революции и переходе всего мира ИТ на ARM, и тут можно было бы выстрелить, а пока всё что я понял и прочитал про архитектуру Эльбруса больше похоже на выстрел в ногу.
Теория заговора
Если погрузиться в теорию заговора, то можно предположить, что специалисты по ARM нужны всему миру, и что если делать ставку на ARM придется конкурировать со всем миром за специалистов, а если специалист заточен на vliw то вероятность что его куда сманят значительно уменьшается. Что то похожее у нас с 1С, ты можешь быть крутым спецом по 1С но за пределами 1С ты не интересен.
Зачем Китаю продавать нам оборудование и знание, если можно значительно дороже продавать нам микросхемы. Я конечно не эксперт в глобальной экономике, но на мой обывательский взгляд, в таких масштабах деньги это просто бумага, а в наше время уже давно не бумага.
Какая выгода китаю от появления конкурентов на рынке?
Вопрос ещё кто нам продаст эти технологии. На мой взгляд не очень умно продавать станки по производству денег из песка. Да наверное 28нм ещё можно продать, не выкидывать же на свалку. Но более современные... сильно сомневаюсь.
И дело даже не в санкциях, просто в чём смысл плодить конкурентов?
Все так и есть, 1С это действительно доступно и всерьез.
Единственное в чем я с вами не согласен так это в масштабе до 1000 человек. Проблем не будет с типовыми решениям до 200-300 пользователей.
Дальше уже начинаются сложности, нужны эксперты которые за этим будут следить. Но даже для 300 человек сложно найти не допиленную типовую, и вот дальше у платформы появляются проблемы:
Неквалифицированные кадры (низкий порог входа, низкие ЗП)
Запредельная сложность крупных конфигураций (Отсутствия ООП, Типизации, Какой либо структуры хранения модулей)
Сложность прикладной части (это отдельная боль).
Отвратительная производительность платформы (тут ниже есть мой пример сравнения с java)
Игнорирование прогресса в разработке СУБД начиная с 92 года. (Газпром вынужден тратить миллиард на сервера СУБД под 1С потому что у 1С есть файловый вариант для ларька который дережит Арсен, и все возможности платформы по работе с СУБД ограниченны этим вариантом).
Жесткий монолит (тут без коментариев, достаточно посмотреть как реализована бесшовная интеграция с документооборотом, я когда смотрю всегда восхищаюсь тем сколько сил и труда было вложено в то что в WEB разработке идет бесплатно).
Сжатые сроки + бизнес на первом месте, а отдел автоматизации где то между завхозом и гаражом, прибыли не приносит, сидят там одни дармоеды и вот это все...)
Причем эти пункты нужно не складывать а перемножать. И
Возьмите любой ORM или тем более современный JS framework там 30% разработчиков не то что не задумываются о том как это реализовано а даже не понимают что там вообще что то под капотом), особенно это касается Frontend.
На самом деле то что 1С позволяет такое писать не проблема 1С, любая ORM с ленивым чтением будет делать то же самое.
Писать так или нет тоже зависит от задачи, ну и для справедливости прям так никто не пишет, это большая редкость. Чаще просто получают через 1-2 точки и это нормально если ты дальше что то делаешь с этим объектом и если у тебя не HiLoad блок а что то что выполняется раз в месяц.
И чаще всего в разыменовываемых объектах не лежат огромные хранилища значений.
При этом СУБД нет особой разницы прочитать один реквизит или прочитать всю строку. Поэтому я бы не стал в большинстве случаев на это обращать внимание.
Нужно просто понимать что ты и для чего делаешь.
Они не нужны там где ты можешь выделить отдельные классы с методами, разместить их в соответствующих каталогах и.т.п. В 1С когда у тебя в одном модуле размещены 95 процедур и 129 функций при этом все они так или иначе вызывают процедуры и функции из других модулей с таким же названием но с другой инструкцией (ПовтИсп, ВызовСервера и.т.п.) комментарии с описанием что это, какие у него параметры жизненно необходимы.
Такое есть везде. Проблема говнокода в 1С встречается чаще из за более низкого порога и сжатых сроков т.к. 80% разработки 1С это разработка по часам. Это примерно как ожидать от продажной женщины за 1500р в час такого же отношения и внимания как от жены.
Но на самом деле проблема такого говнокода это все же проблема того кто пишет и команды (правда в 1С опять же 70% работает без команды). Но никак не платформы и не языка.
Это не java как минимум потому что нет ООП что делает поддержку крупных проектов практически не возможной, и местами героической.
Вторым важным отличием является отсутствие типизации, компилятор вам редко когда что то может подсказать или как то иначе помочь. Надежда только на себя и свою память.
Представьте java без ООП (У вас есть только процедуры и функции) в котором перемешаны SQL запросы, всё это в 350 модулях в одном каталоге (иерархия хранения модулей не поддерживается) каждый модуль от 1000 до 20 000 строк (иначе модулей было бы не 350), эти модули сильно между собой зависимы и по факту просто содержат процедуры и функции, нет интерфейсов, контрактов, каких либо других описаний, ты просто должен всё это помнить сам.
Есть пара стандартов на бумаге где и что размещать но всё это абсолютно не поддерживается средой разработки и языком, иногда складывается впечатление что платформу разрабатывает не крупнейшая в РФ корпорация а просто open source сообщество.
С другой стороны понятно что бейсик (а по факту 1С это и есть бейсик только с фреймворком в виде платформы) не предназначен для всего того куда сейчас платформу продвигают.
1С отличная система с низким порогом входа пока у вас небольшая конфигурация (что редко) или пока вы правите какие то редкие куски большой конфигурации или делаете отчеты/обработки (чем занимается 90% франчей).
В Java перебравшись через порог новичок идет по ступенькам с перилами (ООП, IDE, Code Review, Патерны, Тесты). В 1С за порогом тебя ждет плато на горизонте которого находится отвесная стена, по которой нужно карабкаться дальше.
На мой взгляд людям которые создали ERP, БСП 3.0 при жизни нужно памятник ставить, настолько титанический труд. Страшно подумать каких бы высот они достигли имея дело с современными промышленными языками.
По факту всё что во всем мире является плохим стилем, в 1С норма по определению. Да у 1С есть стандарты разработки, но они на "бумаге" а не в IDE и следовать им это значит ещё сильнее нагрузить свой мозг борьбой с 1С а не решением проблем.
Да и быстродействие 1С это грусть печаль, если JVM оптимизируют всем миром, то виртуальная машина 1С написана в соответствии с первым постулатом "Главное, чтобы работало".
Для примера: Массив из 33 000 000 машинных номеров.
1С:
Формирование массива: 901 156 мс (Цикл + генератор случайных чисел+массив.Добавить(Значение)).
Поиск в массиве не существующего элемента средствами платформы: 19164мс. (Массив.Найти(Значение))
Занимает 2.7 гб RAM.
Java (такой же код на той же системе):
Формирование массива: 52651.3931 мс
Поиск в массиве не существующего элемента : 190.6821 мс (arr.contains(Value))
В памяти точно не помню, по моему около 300 мб.
Вообще там такой багаж проблем (стоимость и вообще необходимость лицензий, ORM ограниченная только урезанным Select которая мощнейшие СУБД с их возможностями использует как замену DBF файлов).
Отдельная боль это гигантомания и монолитизация всего, базы по 2-3 TB на крупных проектах это норма. Когда спрашиваешь у разработчиков PG совета как бы заставить этого монстра работать, в ответ всегда получаешь:
- "Зачем вам такая база?" Разбейте на 10-20 поменьше, выделите сервисы, какие то данные перекиньте в архив и.т.п).
После упоминания что это 1С обычно разговор заканчивается, потому что говорить тут просто не о чем.
Альтернативы нет, так как в крупном ent нет 1С, в лучшем случае прикладные решения (бух,зуп) делать им конкурентов долго, дорого а выхлоп только за счет массовости, а это своя сеть продаж и.т.п. Плюс с локом на РФ. Кому это счастье нужно?
Посмотрите на современный мир, не кто не хочет продавать коробку, все продают сервисы, в для этого 1С не подходит в принципе. Да фреш прикрутили но это для малых ИП и в целом костыль (так как монолит).
Если речь о платформе на которой можно быстро выдать продукт, так есть масса фреймворков, может чуть сложнее порог входа, но это и к лучшему, плюс за счет ООП фреймворки на порядок гибче.
В общем если коротко то рынок который заняла 1С не интересен т.к. уже устарел там нет перспектив, поэтому и желающих нет.
И только в 1С ты должен и интерфейсы проектировать и предметную область знать, и в SQL разбираться + чемодан сюрпризов самой платформы + управляемые блокировки.
А ЗП у тебя будет по низу ИТ рынка.
Кто из разработчиков получает меньше 1С ников?
= small project = small money.
Как OneScript помогает решать проблемы с лицензиями и главное извращенной архитектурой БД?
Что бы делать хотя бы часть из описанного в agenda нужно быть не слабым JS разработчиком. Я как то просил знакомого фулстек помочь вытянуть мне данные из WEB клиента (нужно было интегрироваться имея доступ только к WEB клиенту). Он провозился несколько дней что то смог сделать что то нет, и говорил о WEB интерфейсе 1С примерно теми же словами что другой знакомый DBA использует когда говорит о том как 1С с СУБД работает.
Может быть освоить просто JS + React (vue) и делать сразу нормальные MVC интерфейсы?
Все выше перечисленное делается разными людьми. Это разработчики 1С делают все выше описанное за 6х человек, а ЗП получают как 70% от одного из этих 6.
А потом хвалятся какая 1С дешёвая и популярная, конечно дешёвая, за счет вашей ЗП и нагрузки, дешевая.
И нужно определиться у нас тут low code или js + css + one script + faas.