Почему 1С не поддерживает параллельные процессы (многоядерность) #629465

Кто что думает по этому поводу?

Потому что гладиолус!

Потому что её писали не настолько умные люди, как ты. Подходит ответ?

А зачем, вся тяжелая логика должна работать/обрабатываться не на 1С а на сервере (постгрес, МССЮЛ) и т.д., вопрос к ним.

нет вот сижу жду пока журнал регистрации думает уже минут 5, при этом одно ядро простаивает

сервер поддерживает, rphostы крутятся на разных ядрах

вчера такая же тема была

у СУБД задачи предоставить данные, а к обрабатыванию данных СУБД никакого отношения не имеет

дайте ссылку пожалуйста

нахрена, например, тонкому клиенту многоядерность?

а как насчет обработки проведения по партиям, которая на одном ядре может сутками выполняться?

для предобработки загружаемых данных.

будь мужиком, оптимизируй, блеать

Давай назови какие знаешь программы, что поддерживает параллельные процессы (многоядерность) ?

потому что она на клиенте.

какая религия мешает это делать на сервере?

Действительно, при операциях ввода-вывода быстродействие процессора является самым "узким" местом и простаивание ядра ОЧЕНЬ критично. )))

Проведение если долго, то ето не в ядрам проблема а в коде, или в скорости работы как раз сервера БД

много потоков = лицензирование по потокам 1с ЖАДНЫЕ да и логика движка сложнее гыгыгыг

Так как в 1с приоритет на Клиент-Серверный вариант то там все было построено на блокировках данных базы, а если они будут обращаться то будут вылетать баги.

в 8.2 для этого нужно передать контекст формы. а если канал слабый то лутше обрабатывать на клиенте и вызывать безконтекстные методы сервера.

Запусти Оперу, ядра простаивать не будут :)

ты правда думаешь что долго из за одного ядра?

Журнал регистрации простой текстовик, как вы себе представляете чтение текстовика в два и больше потоков? Гугл хром

на сервере то же самое, не будет одна обработка использовать больше одного ядра

как напишешь

религия практики проектирования системп распределенных  вычислений.

Про Гугл хром, не угадал: он тупо запускает каждую вкладку в отдельном процессе, а не например обработку загрузки и показа одной страницы на 8-ми ядрах, это не совсем то

а можно написать чтоб задействовать свободные ядра? как?

Как у тебя журнал регистрации загрузить целое ядро? Он вообще тупо из системы хранения читает и все.

да потому что у проведение по партиям типовая реализация не очень, её обычно переписывают и ускоряемся в разы....

Не то, отдельные процессы, это хорошо, но для правильной многопоточности и распаралеливания, надо чтоб ядро умело одной задачей грузить все ядра

в прав. одна обработка работает под одним сеансом, один сеанс ложится только на один rphost, а один рпхост только на одно ядро.

rar

И вообще распределение задачи по ядрам это функция ОС. Ее либо используешь когда программируешь либо нет. Поправьте если не прав?

Я из програм что умеют себя распаралеливать по ядрам один раз только видел какой то обработчик видео, и все :(

WinRar еще. И этот Battlefield!

если некую задачу разбить на фоновые задачи, то они грузят все ядра. и грузят прилично.

да, но в языке разработки разработчик описывает логику распаллеливания. В 1С почему то не делают этого

ТС - журнал регистрации - это файло как ты его многопоточно читать то будеш ?

а синхронизировать их как будеш ну типо оператор lock же нету или класса mutex?

Потому что им еще выпускать версию 9...

кто мешает локи самому сделать?

Проверил: Winrar только при упаковке грузит ядра, при распаковке только одно :)

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

в цикле ожидать завершения всех задач. через обработчик ожидания наверное еще можно.

если стоит мощный сервак с мощной СУБД и при проведении по партиям СУБД практически простаивает, то это вопрос к платформе больше, так как узкое место процессор. Поправьте если я не прав?

линейные преобразования прекрано рапараллеливаются . к ним можно отнести 1/3 кода задачи 1с програмирования. вот интересный сайт на тему многопоточности и 1с

В УФ формирование отчета выполняется на одном ядре. В это время ты можешь работать, загружая другое ядро

так это и не ясно, почему 1С в платформе не делает поддержки методов и функций для создания и синхронизации процессов

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

Первый поток спереду, второй сзаду. Втретятся посередине :-) Уже ускорение в два раза. :-)

а вот если бы надо было записать все в 1 файл а обработать в 3 фоновых  то пришлось бы ждать когда обработку завершат все 3 и записывать в том который вызвал 3 фоновых вот тут было бы на 1С гораздо сложнее.

согласен. это кстати официальная позиция 1С по многим вопросам

потому что это ни к чему.

Там и без организации параллельных потоков глюков хватает...Так что лучше не надо

+ и кстати. Многоядерность и много поточночть - это как бы разные вещи.

в 8.2, кстати, намного лучше фоновые работают

Фоновые - это пример многопоточности Win 95. Она на самом деле не была многозадачной. Просто по прерыванию один поток прерывал выполнение других и какое то время выполнялся, а потом по таймеру отдавал управление обратно

это только на файловой, на клиент-серверной реально параллельно выполняются

Споить не буду.Не проверял лично.

Нахрена в ларьках многоядерность?

Нахрен мне ваши сервер не упал! У меня все базы файловые!!

7 ядер простаивает :(

и все равно как правильно заметили выше "одна обработка работает под одним сеансом, один сеанс ложится только на один rphost, а один рпхост только на одно ядро"

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

+1

Я писал прогу распределенных вычислений по сети (по компам раскидывала брутфорс на xor). Это писец такое писать. Но это куйня. Писец такое отлаживать.

Вообще я куею от того, что доблесные спецы делают все на сервере, в то время, как весь мир идет к распределенным вычислениям. Это конечно годно, когда нужны данные в процессе, но если нет, или данных немного - отлично все можно сделать на клиенте.

а я вообще за то, чтобы проведение делалось прямо на сервере баз данных

Я писал рабочее место для менеджера заказов поставщиков...Со всеми их формулами и 3-6 месячными прогнозами Твой распределенные нервно курит в стронке.

а в управляемом приложении оно где то еще может провестись?

На СУБД имелось ввиду?

Это конечно да. Скорость сразу на порядок быстрее.Нет лишних издержек. Все делается на СУБД. У нас у 7-и клиентов к примеру реализована большая логика напрямую на SQL.Причем у двух БД не на 1С.Мне к примеру одно время PLSQL стал как родной.(да и TSQL тоже, хотя сейчас подзабыл). Сейчас готовлю доклад для MSSQL club на тему параллельных вычеслений для MSSQL(TSQL).

Глупость:-)

+Уж извини

Реальные спецы, я так посмотрю, меряются логарифмической линейкой.

Думаю, первый вопрос политический. 1С должна "разрабатываться" на 1С языке. Второй вопрос это унификация (MSSQL, ORACLE,DB2, файловая версия).Хотя из них только MSSQL можно считать корпоративным стандартом(мое мнение).

Да ты вообще не в теме.. 1С -  и DOS...   Это тема.

Как наладить соответствие?...Никто же даже не думал!

Мы все умрем..Я так и знал.

, Проблема основная в сопровождении изменений. Сложно будет вести один и тот же код(логику) на TSQL(PLSQL) и на 1С. Нужно выбирать что то одно.  Тогда пришлось бы генерить автоматически читаемые views.(мы такое делали для онлайн интеграции с web). Но в этом случае вопрос нелицензионного использования(точнее его контроля) усложняется серьезно технически. Мое мнение что это одна из основных проблем для официального открытия 1С доступа напрямую к данным.

Все равно ... Эхх...

Мне вот только интересно, чего ожидают , присутствующие в этой теме?6-))) Что бы ЭХХ  было прям сейчас, а вы успели запастись попкорном?. Обойдетесь.

спасибо за внимание, можете расходиться.

Нет дискусии, а мне много чего есть сказать на эту тему:)

Подведу итог. Тренд на ближайшие 20 лет - параллельные вычисления.(там возможно квантовые суперэвм появятся) Только вот плюсы от их использования пока не покрывают минусы(трудно и дорого). Думаю это произойдет через 5-10 лет.