Народ, хотелось бы научить обработку работать на 2 потока - когда-нибудь будет реализована такая возможность??? Как считаете???

(99) Рассматривал. Но речь идет Документы, Денис!

Карл, Фридрих-Иероним!

(97) Это бессмысленно. Операция интерактивного проведения документа синхронна по своей природе. Пользователь в любом случае будет ждать окончания, прежде, чем станет делать что-то дальше.

А вот чтобы ждать ему приходилось поменьше, неплохо бы дать разработчику возможность алгоритмы проведения распараллелить. В том числе в файловом режиме, на клиенте. Особенно в файловом режиме.

(98) Синхронный GUI это фиг с ним, можно перетерпеть. А вот многопоточное выполнение кода нужно.

(103) А как же отложенное проведение. И есть по сути асинхронное

(103) "алгоритмы проведения распараллелить"
да это же невозможно. там нечего распараллеливать. диск ты всё равно не распараллелишь.

2(105) господи, да легко - сколько шпинделей - столько и записей. А если буферпулы настроить на максимум, так вообще

(106) ты регистры будешь по шпинделям распределять? ну ну.

(105) Да ну? А расчет зарплаты? А расчет себестоимости? А выравнивание партий? Что у нас там еще долго проводится?..

До возможностей диска там как до луны.

(107) бывают ведь ссд

(108) в упп партии отлично параллелятся: отдельно БУ, отдельно НУ

2(107) Сервер БД их будет распределять

(104) Есть. Но это другое. А при интерактивном надо сейчас.

нет, собственно даже не сервер, а контроллер диска, то есть файловая система. А Сервер БД будет стараться их держать в буферпулах, и только со временем экстренализировать на диски

(113) не все так радужно как ты думаешь

2(114) ты не можешь знать как я думаю и как я делаю.

(105) Какой диск?? БД в памяти вся балтается

(107) Я распределял. Лучше было

(116) Это у вас детских размеров БД.

2(118) для недетских есть тэйблспейсы, который... чорд, опять болтаются в памяти целиком

(118) Сколько весит твоя?

Как минимум нужна многопоточность в конфигураторе при обновлении. Там ничего сложного все распаралелить

Используем фоновые для проведения кучи документов. Профит 8 часов против последовательного 50 + часов

+(121) Лично мне бы это экономило десяток-другой рабочих часов в месяц. Думаю по всей отрасли это бы исчислялось сотнями тысяч человеко-часов в месяц экономии, причем не абы кого, а квалифицированных специалистов.

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

не забываем про закон Амдала

(124) ерунда

Я когда видео декодировал с DVD в mp4, двухядерный проц гораздо быстрее это делал. чудеса?

(124) Хотят просто писать в разные таблицы. И тут будет в разы.

(126) одноядерный P4 против двухъядерного i5 ?

(127) ну можно попробовать. для начала, запустить два раза одну базу и засечь время на добавление в два справочника 100000 записей например. потом запустить одну и сделать тоже самое два раза подряд. засечь время.

(128) Athlon64 и Athlon64 X2 .. одни из первых

Как я уже написал в статье на Инфостарте, мы уже юзаем универсальные многопоточные обработки: объединение дублей, обмен данными, свертка регистров, произвольная обработка объектов. Действительно к квалификации разработчика при переходе к многопоточности повышаются требования. Рано или поздно в БСП появится подсистема "Многопоточные обработки данных". У многих в том или ином виде она уже есть. Без подсистемы многопоточность при работе с данными кодировать с нуля весьма неэффективно.

(130) ну само собой, если программа может использовать несколько ядер процессора, то прирост будет. но применительно к 1с ждать увеличения производительности в разы, даже если 1с будет использовать несколько ядер - глупо.

Многопоточность нужна.
Например, массовая рассылка прайсов, когда часто приходится рассчитывать и отправлять по 1000 штук.
Пробовал через фоновые задания - тяжело идет.
Фоновые задания в текущем виде - это тормоза. Тяжело запускаются, а результат возвращают через задний проход.
Запуск каждого задания - это несколько секунд, и если задача мелкая (прайс формируется несколько секунд) - дольше ждать запуска этого задания.

(126) в библиотеках для кодирования в мп4 _специально_ установлены многопоточно выполняемые _расчеты_, обращаю особое внимание на выполнение _Расчетов_, а операций ввода-вывода на диск. Более того, именно специфика обработки данных с кадрами сжатия в мп4 - это когда берутся достаточно большие куски видео без сжатия (последовательность кадров) и в них от опорных кадров сохраняют последовательности сжатых изменений.
Естественно, что разные опорные кадры с последовательными блоками несжатых кадров очень эффектно можно сливать в разные потоки на разные (и действительно разные) ядра. И это все обязательно происходит в _выделенной_ оперативной памяти, иначе не получится запросить у планировщика и получить от него еще одно новое ядро на еще один новый поток

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

я в ЗИК 7.7 рассчитывал налоги из нескольких копий программы по разным подразделениям одновременно...прирост скорости действительно в разы в итоге получался

при правильном подходе многопоточность может сильно помочь

(135) а я наоборот всегда делаю последовательно, потому что кроме нагрева системы ничего не увеличивается.

(135) изоляция рабочих наборов данных это действительно мощная штука. Иначе транзакция тебя просто поставит в очередь и все.

(124) Запусти на i7 c 32 Гб оперативки и SSD обновлять несколько баз последовательно, а затем параллельно и подсчитай многократный выигришь в скорости.

(137) угу...так считать 500 человек 60 минут, а параллельно за 15...ничё не увеличивается совсем...особенно когда на улице 8 вечера..а дома жена ждёт

(137) но виртуально сложно оценить насколько изолированы получались данные друг от друга.

(140) как у тебя эти 500 разделены были? в разных документах расчетов, т.е. в разных табличных частях и т.п.?

(140) а я никогда на работе не задерживаюсь. закон такой.

(141) ЗиК 7.7, там было понятие журнала расчётов, и рассчитывалось всё отдельной обработкой.
разделены по разным подразделениям
(142) а это у меня "удалёнка", и во времена хренового интернета приходилось туда ездить физически

(103)
>> Синхронный GUI это фиг с ним, можно перетерпеть.
>> А вот многопоточное выполнение кода нужно.
Все наоборот.
Как раз GUI должен быть "живым" и быстрым.
Чтобы нажал "записать и закрыть" - сервер сказал "Ок, записываю...", а ты тем временем можешь начать ввод данных в следующий документ.

На это нацелена асинхронность в веб-приложениях.
А не так, что ты нажал кнопку - и сервер убежал думать, а ты пошел за чаем.

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

(143) угу. вспомнил. главное, чтоб список выбранных сотрудников не пересекался. Самое смешное, что я так сам тоже делал. Сколько уже лет прошло... Отбираемые сотры по подразделениям, чтоб не повторялись в разных сеансах и погнали :) А если на разных компах, то и вообще красота. Компы тогда не могли похвастаться "лишними" ядрами.

>Чтобы нажал "записать и закрыть" - сервер сказал "Ок, записываю...", а ты тем временем можешь начать ввод данных в следующий документ.

до сих пор нет 64-битного клиента под винду... какие там "ок, записываю"

(146) кстати, сам не смотрел, а для линукса там какие клиенты? Тоже 32 бита? Хотя, большой разницы только одно это не даст.

(140)получается, чем больше система тратит время процессора, тем больше чудес можно ждать от распараллеливания. если бы 1с была офигенно быстрой и не тратила время процессора на какую-то фигню, то она упиралась бы только в запись на диск.

(147) под пингвина есть 64... но у кого есть пингвин?

это даст хотя бы то что клиент и пофигуратор не будут падать от объемных операций

>если бы 1с была офигенно быстрой

она в 10 раз медленнее дельфей. и можно ли с этим что-то сделать? интерпретатор же

(148) под многопоточность надо писать правильные программы

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

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

(150) я думаю, что и интерпретатор можно сделать быстрее нынешнего раз эдак в 5.

(150)
>> интерпретатор же
Это отмазка :).
Интерпретаторы тоже могут быть быстрыми, это по большому счету претензия к компилятору.

Да и дело наверное не в интерпретаторе. Никто же не пишет циклы на миллионы итераций и не вычисляет числа Фибоначчи. Оно просто внутри тормознутое и нам с этим жить. И довольно неплохо в материальном плане. :)

(98) Это не только с 1С. Очередь сообщений привязана к потоку. Обращайся к GUI из её потока.

А вообще в нормальных языках большинство функций асинхронны

http://www.codeproject.com/Tips/8059...PI-ASP-NET-MVC

Я вообще промолчу про ленивые функции итд.

http://www.codeproject.com/Tips/805923/Asynchronous-programming-in-Web-API-ASP-NET-MVC

(133) Это как раз пример неправильного использования многопоточности.

> если задача мелкая (прайс формируется несколько секунд) - дольше ждать запуска этого задания.

Так запускать надо один раз. Раскидать всю пачку по заданиям, каждому по 200 клиентов, допустим, и пускай формируют и сразу рассылают.

(158) Та же многопоточность, только вручную. Так и делаем.

Только - виндовым планировщиком, так надежнее.

(144) >Как раз GUI должен быть "живым" и быстрым.
Против этого не возразишь.

>Чтобы нажал "записать и закрыть" - сервер сказал "Ок, записываю...", а ты тем временем можешь начать ввод данных в следующий документ.

Только бухи так делать не будут. Они сначала убеждаются, что док провелся корректно и так, как им нужно.
А если сделать так, что набил половину следующего, а тут бац - предыдущий ругается: где-то что-то не так заполнил. От частого переключения контекста у юзеров крышу сносит и они идут тебя бить.

(156) Асинхронность у нас уже есть.

(161) Согласен, что бухи так делать не будут. Ну ведь 1с утверждает, что она не только в бухе хороша, но и почти в любых учетный системах не связанных с бухгатерией.

(162) Как говорят в 1С: Не путайте асинхронность и многопточность

Но в 1С как всегда: бессмысленная однопоточная асинхронность

(163) Если документ после ввода не требует контроля со стороны системы, то его и проводить не надо, просто сохранить. А проводить можно и фоновым заданием.

А сохраняет 1С быстро, тут многопоточность не нужна.

Бойтесь своих желаний... А то будут при сдаче на сертификате что-нить такое спрашивать: https://www.youtube.com/watch?v=iB2N8aqwtxc

(162) Кроме фоновых заданий асинхронности нет. Асинхронность это не только запуск потока для выплнения метода, но и отправка запроса и получении результата по событию. А на каждый метод фоновых заданий не наберешься.

(168) А как же "начать задавать вопрос"?

(161)
>> набил половину следующего, а тут бац - предыдущий ругается: где-то что-то не так заполнил

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

>> ... бухи ... сначала убеждаются, что док провелся корректно и так, как им нужно.

Программа должна работать корректно. А если пользователь перепроверяет (испытывает недоверие) - либо такой пользователь (и ему ничем уже не помочь), либо это вина программы.

(169) Не понял?

(171) Асинхронные методы, один из которых ПоказатьВопрос()

НачатьПомещениеФайла и тд и тп

Это не асинхронные методы, а продолжатели которые выполняются в одном потоке. Не надо путать с модальностью.
Примером асинхронности это AJAX.
Или элементарный пример чтения данных из COM порта

sp = new SerialPort("COM" + НомерПорта.ToString());

            sp.BaudRate = 9600;
            sp.Parity = Parity.None;
            sp.StopBits = StopBits.One;
            sp.DataBits = 8;
            sp.Handshake = Handshake.None;

            sp.DataReceived += (sender, e) => {
                SerialPort sp1 = (SerialPort)sender;
                string indata = sp1.ReadExisting();
              
                    Sc.Send(d => EventTo1C.ExternalEvent("ДанныеОтСканера", sp1.PortName, indata), null);
                    

            };

            sp.Open();

(174) См (164) до просветления

(175) И?

http://habrahabr.ru/post/51762/

https://msdn.microsoft.com/ru-ru/library/hh191443.aspx

И где противоречие?

https://msdn.microsoft.com/en-us/data/jj819165.aspx
(179) Противоречие с чем?

(172) Это не что иное как подписка на событие ПриЗакрытии.

(167) Хрень какая-то.

181 в 7.7 Тоже для возврата результата в вызвавшую форму применяли Открытие Формы родителя, а внутри использовали метод ПриПовторномОткрытии. Но почему то тогда никто не называл этот прием асинхронным программированием

(182) Разработчик JVM рассказывает о том, как реализована поддержка многопоточности в JVM)
И почему реализована именно так.

(174) >Это не асинхронные методы, а продолжатели которые выполняются в одном потоке.
WAT?

(185) "Продолжатели", которые запускают доп. потоки обработки и передают им точки вызова при завершении. Все по классике.

(186) Господи, как тока callback'и не обзывают.
И да, по классике callback'и никак не связаны с multithreading'ом)

У нас многопоточность используется через фоновые задания. Чтобы заполнять отчетность параллельно. Прирост заполнения в несколько раз по сравнению с последовательным заполнением (до 10 потоков). Итоговый выигрыш в несколько часов. Единственное, иногда фоновые задания отваливаются и приходится это отслеживать в отдельном фоновом задании.

(186) С точки зрения асинхронного программирования синхронный метод блокирует рабочий поток. За счет того, что метод выполняется в рабочем потоке либо ожидает завершения асинхронного метода (работа с сокетами) с помощью объектов синхронизации до получения события (монитор, мьютекс).
С этой точки зрения вызов модального окна не является синхронным, так как его очередь работает в этом же потоке, можно вызвать методы в этом же потоке. Спецификой модального окна является то, что оно перехватывает все события другим окнам приложения, и после выполнение возврат кода происходит на следующий оператор за вызовом модального окна. Никакого отношения к асинхронному прогпаммированию модальное окно не имеет.

(187) Под продолжателями я имел ввиду делегаты вызываемые при событии ПриЗакрытии. Никакого отношения к асинхронному программированию они не имеют.

(189) (190) Кончай теоретизировть. Речь шла о методе ПоказатьВопрос() и ему подобных. Обработчик, передаваемый туда, выполняется асинхронно. Вот я и возмутился.

(92) С чего ты взял, что у процесса только 1 ядро доступно? По умолчанию доступны все ядра, если только affinity mask не задать.

(192) Кнечно - гляньте любой архиватор

(105) IOPs'ы у HDD при произвольном доступе растут по мере роста глубины очереди запросов, если чо. Так что 10-20-30% прироста вполне можно получить даже если тормоз - HDD.

(121) Хочешь глюков в Конфигураторе? Они с 1 рабочим потоком-то не могут целостность кеша отладить уже лет 10...

Какой к черту многопоточность. Если уже на носу 8.3.6 и вот вот будет (7). А 1С так и не научилась с сервера возвращать параметр "Я обработка, я не вишу и работаю, вот осталось еще 10% и я вам выдам результат". Я про тонкий клиент.

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

(194) Да сделайте уже нулевой рейд или 10 ый

(193) Глянул 7-Zip. На 6 ядрах скорость в 4-5 раз выше.

(196) Зачем этот колхоз? С приходом SSD для повышения быстродействия он стал абсолютно ненужен.

(192) Он имеет ввиду, что  2 потока одновременно НА ОДНОМ ядре  не могут работать.

(198) Слава HyperThreading - могут ;) И я бы не стал на это рассчитывать - куча программистов наступила на эти грабли, когда их ПО жестко глючило на многоядерных ЦП.

(191) Это не теория а практика. Ты можешь как угодно называть немодальные диалоги и подписку на события, только к реальному асинхронному программированию оно никакого отношения не имеет.