Имя: Пароль:
1C
1С v8
Когда-нибудь будет многопоточность?
, , ,
0 Маленький Вопросик
 
19.08.15
20:07
Народ, хотелось бы научить обработку работать на 2 потока - когда-нибудь будет реализована такая возможность??? Как считаете???
101 H A D G E H O G s
 
20.08.15
14:27
(99) Рассматривал. Но речь идет Документы, Денис!
102 Живой Ископаемый
 
20.08.15
14:29
Карл, Фридрих-Иероним!
103 mistеr
 
20.08.15
14:42
(97) Это бессмысленно. Операция интерактивного проведения документа синхронна по своей природе. Пользователь в любом случае будет ждать окончания, прежде, чем станет делать что-то дальше.

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

(98) Синхронный GUI это фиг с ним, можно перетерпеть. А вот многопоточное выполнение кода нужно.
104 Гёдза
 
20.08.15
14:45
(103) А как же отложенное проведение. И есть по сути асинхронное
105 Кирпич
 
20.08.15
14:46
(103) "алгоритмы проведения распараллелить"
да это же невозможно. там нечего распараллеливать. диск ты всё равно не распараллелишь.
106 Живой Ископаемый
 
20.08.15
14:48
2(105) господи, да легко - сколько шпинделей - столько и записей. А если буферпулы настроить на максимум, так вообще
107 Кирпич
 
20.08.15
14:49
(106) ты регистры будешь по шпинделям распределять? ну ну.
108 mistеr
 
20.08.15
14:50
(105) Да ну? А расчет зарплаты? А расчет себестоимости? А выравнивание партий? Что у нас там еще долго проводится?..

До возможностей диска там как до луны.
109 Гёдза
 
20.08.15
14:50
(107) бывают ведь ссд
110 Гёдза
 
20.08.15
14:51
(108) в упп партии отлично параллелятся: отдельно БУ, отдельно НУ
111 Живой Ископаемый
 
20.08.15
14:52
2(107) Сервер БД их будет распределять
112 mistеr
 
20.08.15
14:52
(104) Есть. Но это другое. А при интерактивном надо сейчас.
113 Живой Ископаемый
 
20.08.15
14:53
нет, собственно даже не сервер, а контроллер диска, то есть файловая система. А Сервер БД будет стараться их держать в буферпулах, и только со временем экстренализировать на диски
114 Гёдза
 
20.08.15
14:56
(113) не все так радужно как ты думаешь
115 Живой Ископаемый
 
20.08.15
14:57
2(114) ты не можешь знать как я думаю и как я делаю.
116 magicSan
 
20.08.15
15:01
(105) Какой диск?? БД в памяти вся балтается
117 ДенисЧ
 
20.08.15
15:04
(107) Я распределял. Лучше было
118 mistеr
 
20.08.15
15:13
(116) Это у вас детских размеров БД.
119 Живой Ископаемый
 
20.08.15
15:16
2(118) для недетских есть тэйблспейсы, который... чорд, опять болтаются в памяти целиком
120 magicSan
 
20.08.15
15:18
(118) Сколько весит твоя?
121 Asirius
 
20.08.15
15:19
Как минимум нужна многопоточность в конфигураторе при обновлении. Там ничего сложного все распаралелить
122 13_Mult
 
20.08.15
15:25
Используем фоновые для проведения кучи документов. Профит 8 часов против последовательного 50 + часов
123 Asirius
 
20.08.15
15:28
+(121) Лично мне бы это экономило десяток-другой рабочих часов в месяц. Думаю по всей отрасли это бы исчислялось сотнями тысяч человеко-часов в месяц экономии, причем не абы кого, а квалифицированных специалистов.
124 Кирпич
 
20.08.15
15:42
вот с чего люди взяли что многопоточность прям в разы увеличит производительность.  
когда у нас будут 1000 ядерные процессоры и 1000 канальная память, тогда можно будет чего то ждать.
просто ради эксперемента, запустите два потока которые будет крутить цикл от 1 до 1000000000 и засеките время выполнения одного из этих потоков. потом запустите один поток на 2000000000. время выполнения двух потоков на 1000000000 и одного на 2000000000 будет одинаково.
я уж молчу про блокировки ресурсов, память, диски и т.д.
125 Гёдза
 
20.08.15
15:45
не забываем про закон Амдала
126 Garikk
 
20.08.15
15:46
(124) ерунда

Я когда видео декодировал с DVD в mp4, двухядерный проц гораздо быстрее это делал. чудеса?
127 magicSan
 
20.08.15
15:46
(124) Хотят просто писать в разные таблицы. И тут будет в разы.
128 Кирпич
 
20.08.15
15:50
(126) одноядерный P4 против двухъядерного i5 ?
129 Кирпич
 
20.08.15
15:55
(127) ну можно попробовать. для начала, запустить два раза одну базу и засечь время на добавление в два справочника 100000 записей например. потом запустить одну и сделать тоже самое два раза подряд. засечь время.
130 Garikk
 
20.08.15
15:56
(128) Athlon64 и Athlon64 X2 .. одни из первых
131 TormozIT
 
гуру
20.08.15
16:01
Как я уже написал в статье на Инфостарте, мы уже юзаем универсальные многопоточные обработки: объединение дублей, обмен данными, свертка регистров, произвольная обработка объектов. Действительно к квалификации разработчика при переходе к многопоточности повышаются требования. Рано или поздно в БСП появится подсистема "Многопоточные обработки данных". У многих в том или ином виде она уже есть. Без подсистемы многопоточность при работе с данными кодировать с нуля весьма неэффективно.
132 Кирпич
 
20.08.15
16:03
(130) ну само собой, если программа может использовать несколько ядер процессора, то прирост будет. но применительно к 1с ждать увеличения производительности в разы, даже если 1с будет использовать несколько ядер - глупо.
133 Зеленый пень
 
20.08.15
16:06
Многопоточность нужна.
Например, массовая рассылка прайсов, когда часто приходится рассчитывать и отправлять по 1000 штук.
Пробовал через фоновые задания - тяжело идет.
Фоновые задания в текущем виде - это тормоза. Тяжело запускаются, а результат возвращают через задний проход.
Запуск каждого задания - это несколько секунд, и если задача мелкая (прайс формируется несколько секунд) - дольше ждать запуска этого задания.
134 Фрэнки
 
20.08.15
16:09
(126) в библиотеках для кодирования в мп4 _специально_ установлены многопоточно выполняемые _расчеты_, обращаю особое внимание на выполнение _Расчетов_, а операций ввода-вывода на диск. Более того, именно специфика обработки данных с кадрами сжатия в мп4 - это когда берутся достаточно большие куски видео без сжатия (последовательность кадров) и в них от опорных кадров сохраняют последовательности сжатых изменений.
Естественно, что разные опорные кадры с последовательными блоками несжатых кадров очень эффектно можно сливать в разные потоки на разные (и действительно разные) ядра. И это все обязательно происходит в _выделенной_ оперативной памяти, иначе не получится запросить у планировщика и получить от него еще одно новое ядро на еще один новый поток

з.ы. прошу не ругать за повторы слов, но я по честному пытаюсь объяснить разницу подходов - когда потоки параллелятся, а когда нет.
135 Garikk
 
20.08.15
16:10
я в ЗИК 7.7 рассчитывал налоги из нескольких копий программы по разным подразделениям одновременно...прирост скорости действительно в разы в итоге получался
136 Garikk
 
20.08.15
16:11
при правильном подходе многопоточность может сильно помочь
137 Кирпич
 
20.08.15
16:12
(135) а я наоборот всегда делаю последовательно, потому что кроме нагрева системы ничего не увеличивается.
138 Фрэнки
 
20.08.15
16:12
(135) изоляция рабочих наборов данных это действительно мощная штука. Иначе транзакция тебя просто поставит в очередь и все.
139 Asirius
 
20.08.15
16:14
(124) Запусти на i7 c 32 Гб оперативки и SSD обновлять несколько баз последовательно, а затем параллельно и подсчитай многократный выигришь в скорости.
140 Garikk
 
20.08.15
16:14
(137) угу...так считать 500 человек 60 минут, а параллельно за 15...ничё не увеличивается совсем...особенно когда на улице 8 вечера..а дома жена ждёт
141 Фрэнки
 
20.08.15
16:15
(137) но виртуально сложно оценить насколько изолированы получались данные друг от друга.

(140) как у тебя эти 500 разделены были? в разных документах расчетов, т.е. в разных табличных частях и т.п.?
142 Кирпич
 
20.08.15
16:16
(140) а я никогда на работе не задерживаюсь. закон такой.
143 Garikk
 
20.08.15
16:17
(141) ЗиК 7.7, там было понятие журнала расчётов, и рассчитывалось всё отдельной обработкой.
разделены по разным подразделениям
(142) а это у меня "удалёнка", и во времена хренового интернета приходилось туда ездить физически
144 BadSanta
 
20.08.15
16:20
(103)
>> Синхронный GUI это фиг с ним, можно перетерпеть.
>> А вот многопоточное выполнение кода нужно.
Все наоборот.
Как раз GUI должен быть "живым" и быстрым.
Чтобы нажал "записать и закрыть" - сервер сказал "Ок, записываю...", а ты тем временем можешь начать ввод данных в следующий документ.

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

Вы представляете что такое многопоточный серверный код?
Простейшая задача - распараллелить обход массива с возможностью удаления элементов в процессе превращается в ад.
145 Фрэнки
 
20.08.15
16:20
(143) угу. вспомнил. главное, чтоб список выбранных сотрудников не пересекался. Самое смешное, что я так сам тоже делал. Сколько уже лет прошло... Отбираемые сотры по подразделениям, чтоб не повторялись в разных сеансах и погнали :) А если на разных компах, то и вообще красота. Компы тогда не могли похвастаться "лишними" ядрами.
146 Господин ПЖ
 
20.08.15
16:28
>Чтобы нажал "записать и закрыть" - сервер сказал "Ок, записываю...", а ты тем временем можешь начать ввод данных в следующий документ.

до сих пор нет 64-битного клиента под винду... какие там "ок, записываю"
147 Фрэнки
 
20.08.15
16:34
(146) кстати, сам не смотрел, а для линукса там какие клиенты? Тоже 32 бита? Хотя, большой разницы только одно это не даст.
148 Кирпич
 
20.08.15
16:35
(140)получается, чем больше система тратит время процессора, тем больше чудес можно ждать от распараллеливания. если бы 1с была офигенно быстрой и не тратила время процессора на какую-то фигню, то она упиралась бы только в запись на диск.
149 Господин ПЖ
 
20.08.15
16:36
(147) под пингвина есть 64... но у кого есть пингвин?

это даст хотя бы то что клиент и пофигуратор не будут падать от объемных операций
150 Господин ПЖ
 
20.08.15
16:37
>если бы 1с была офигенно быстрой

она в 10 раз медленнее дельфей. и можно ли с этим что-то сделать? интерпретатор же
151 Garikk
 
20.08.15
16:43
(148) под многопоточность надо писать правильные программы

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

просто тупо "сделать многопоточную платформу" тут не получится. надо каждую конкретную задачу рассчитывать под распараллеливание
152 Кирпич
 
20.08.15
16:43
(150) я думаю, что и интерпретатор можно сделать быстрее нынешнего раз эдак в 5.
153 BadSanta
 
20.08.15
16:45
(150)
>> интерпретатор же
Это отмазка :).
Интерпретаторы тоже могут быть быстрыми, это по большому счету претензия к компилятору.
154 Кирпич
 
20.08.15
17:00
Да и дело наверное не в интерпретаторе. Никто же не пишет циклы на миллионы итераций и не вычисляет числа Фибоначчи. Оно просто внутри тормознутое и нам с этим жить. И довольно неплохо в материальном плане. :)
155 Serginio1
 
20.08.15
17:01
(98) Это не только с 1С. Очередь сообщений привязана к потоку. Обращайся к GUI из её потока.
156 Serginio1
 
20.08.15
17:15
А вообще в нормальных языках большинство функций асинхронны

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

Я вообще промолчу про ленивые функции итд.
157 Serginio1
 
20.08.15
17:16
158 mistеr
 
20.08.15
17:29
(133) Это как раз пример неправильного использования многопоточности.

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

Так запускать надо один раз. Раскидать всю пачку по заданиям, каждому по 200 клиентов, допустим, и пускай формируют и сразу рассылают.
159 Зеленый пень
 
20.08.15
17:31
(158) Та же многопоточность, только вручную. Так и делаем.
160 Зеленый пень
 
20.08.15
17:32
Только - виндовым планировщиком, так надежнее.
161 mistеr
 
20.08.15
17:35
(144) >Как раз GUI должен быть "живым" и быстрым.
Против этого не возразишь.

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

Только бухи так делать не будут. Они сначала убеждаются, что док провелся корректно и так, как им нужно.
А если сделать так, что набил половину следующего, а тут бац - предыдущий ругается: где-то что-то не так заполнил. От частого переключения контекста у юзеров крышу сносит и они идут тебя бить.
162 mistеr
 
20.08.15
17:35
(156) Асинхронность у нас уже есть.
163 qwerty2469
 
20.08.15
17:41
(161) Согласен, что бухи так делать не будут. Ну ведь 1с утверждает, что она не только в бухе хороша, но и почти в любых учетный системах не связанных с бухгатерией.
164 Гёдза
 
20.08.15
17:46
(162) Как говорят в 1С: Не путайте асинхронность и многопточность
165 Гёдза
 
20.08.15
17:48
Но в 1С как всегда: бессмысленная однопоточная асинхронность
166 mistеr
 
20.08.15
17:52
(163) Если документ после ввода не требует контроля со стороны системы, то его и проводить не надо, просто сохранить. А проводить можно и фоновым заданием.

А сохраняет 1С быстро, тут многопоточность не нужна.
167 tridog
 
20.08.15
17:56
Бойтесь своих желаний... А то будут при сдаче на сертификате что-нить такое спрашивать: https://www.youtube.com/watch?v=iB2N8aqwtxc
168 Serginio1
 
20.08.15
17:59
(162) Кроме фоновых заданий асинхронности нет. Асинхронность это не только запуск потока для выплнения метода, но и отправка запроса и получении результата по событию. А на каждый метод фоновых заданий не наберешься.
169 Гёдза
 
20.08.15
18:02
(168) А как же "начать задавать вопрос"?
170 BadSanta
 
20.08.15
18:05
(161)
>> набил половину следующего, а тут бац - предыдущий ругается: где-то что-то не так заполнил

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

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

Программа должна работать корректно. А если пользователь перепроверяет (испытывает недоверие) - либо такой пользователь (и ему ничем уже не помочь), либо это вина программы.
171 Serginio1
 
20.08.15
18:08
(169) Не понял?
172 Гёдза
 
20.08.15
18:11
(171) Асинхронные методы, один из которых ПоказатьВопрос()
173 Гёдза
 
20.08.15
18:11
НачатьПомещениеФайла и тд и тп
174 Serginio1
 
20.08.15
18:14
Это не асинхронные методы, а продолжатели которые выполняются в одном потоке. Не надо путать с модальностью.
Примером асинхронности это 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();
175 Гёдза
 
20.08.15
18:14
(174) См (164) до просветления
176 Serginio1
 
20.08.15
18:15
(175) И?
177 Serginio1
 
20.08.15
18:16
178 Serginio1
 
20.08.15
18:20
179 Гёдза
 
20.08.15
18:21
И где противоречие?
180 Serginio1
 
20.08.15
18:23
https://msdn.microsoft.com/en-us/data/jj819165.aspx
(179) Противоречие с чем?
181 Serginio1
 
20.08.15
18:28
(172) Это не что иное как подписка на событие ПриЗакрытии.
182 H A D G E H O G s
 
20.08.15
18:28
(167) Хрень какая-то.
183 Serginio1
 
20.08.15
18:37
181 в 7.7 Тоже для возврата результата в вызвавшую форму применяли Открытие Формы родителя, а внутри использовали метод ПриПовторномОткрытии. Но почему то тогда никто не называл этот прием асинхронным программированием
184 tridog
 
20.08.15
19:33
(182) Разработчик JVM рассказывает о том, как реализована поддержка многопоточности в JVM)
И почему реализована именно так.
185 mistеr
 
20.08.15
20:13
(174) >Это не асинхронные методы, а продолжатели которые выполняются в одном потоке.
WAT?
186 H A D G E H O G s
 
20.08.15
20:17
(185) "Продолжатели", которые запускают доп. потоки обработки и передают им точки вызова при завершении. Все по классике.
187 tridog
 
20.08.15
22:52
(186) Господи, как тока callback'и не обзывают.
И да, по классике callback'и никак не связаны с multithreading'ом)
188 GenV
 
20.08.15
23:02
У нас многопоточность используется через фоновые задания. Чтобы заполнять отчетность параллельно. Прирост заполнения в несколько раз по сравнению с последовательным заполнением (до 10 потоков). Итоговый выигрыш в несколько часов. Единственное, иногда фоновые задания отваливаются и приходится это отслеживать в отдельном фоновом задании.
189 Serginio1
 
20.08.15
23:09
(186) С точки зрения асинхронного программирования синхронный метод блокирует рабочий поток. За счет того, что метод выполняется в рабочем потоке либо ожидает завершения асинхронного метода (работа с сокетами) с помощью объектов синхронизации до получения события (монитор, мьютекс).
С этой точки зрения вызов модального окна не является синхронным, так как его очередь работает в этом же потоке, можно вызвать методы в этом же потоке. Спецификой модального окна является то, что оно перехватывает все события другим окнам приложения, и после выполнение возврат кода происходит на следующий оператор за вызовом модального окна. Никакого отношения к асинхронному прогпаммированию модальное окно не имеет.
190 Serginio1
 
20.08.15
23:44
(187) Под продолжателями я имел ввиду делегаты вызываемые при событии ПриЗакрытии. Никакого отношения к асинхронному программированию они не имеют.
191 mistеr
 
21.08.15
00:53
(189) (190) Кончай теоретизировть. Речь шла о методе ПоказатьВопрос() и ему подобных. Обработчик, передаваемый туда, выполняется асинхронно. Вот я и возмутился.
192 dmpl
 
21.08.15
07:11
(92) С чего ты взял, что у процесса только 1 ядро доступно? По умолчанию доступны все ядра, если только affinity mask не задать.
193 magicSan
 
21.08.15
07:15
(192) Кнечно - гляньте любой архиватор
194 dmpl
 
21.08.15
07:20
(105) IOPs'ы у HDD при произвольном доступе растут по мере роста глубины очереди запросов, если чо. Так что 10-20-30% прироста вполне можно получить даже если тормоз - HDD.

(121) Хочешь глюков в Конфигураторе? Они с 1 рабочим потоком-то не могут целостность кеша отладить уже лет 10...
195 ЧеловекДуши
 
21.08.15
07:23
Какой к черту многопоточность. Если уже на носу 8.3.6 и вот вот будет (7). А 1С так и не научилась с сервера возвращать параметр "Я обработка, я не вишу и работаю, вот осталось еще 10% и я вам выдам результат". Я про тонкий клиент.

Пользователь сидит, и непонятно, завершится мего отчет успехом, либо вылетит, либо пользователь соберется домой :)
196 magicSan
 
21.08.15
07:24
(194) Да сделайте уже нулевой рейд или 10 ый
197 dmpl
 
21.08.15
07:28
(193) Глянул 7-Zip. На 6 ядрах скорость в 4-5 раз выше.

(196) Зачем этот колхоз? С приходом SSD для повышения быстродействия он стал абсолютно ненужен.
198 qwerty2469
 
21.08.15
09:51
(192) Он имеет ввиду, что  2 потока одновременно НА ОДНОМ ядре  не могут работать.
199 dmpl
 
21.08.15
10:14
(198) Слава HyperThreading - могут ;) И я бы не стал на это рассчитывать - куча программистов наступила на эти грабли, когда их ПО жестко глючило на многоядерных ЦП.
200 Serginio1
 
21.08.15
10:26
(191) Это не теория а практика. Ты можешь как угодно называть немодальные диалоги и подписку на события, только к реальному асинхронному программированию оно никакого отношения не имеет.
Пользователь не знает, чего он хочет, пока не увидит то, что он получил. Эдвард Йодан