|
Когда-нибудь будет многопоточность? | ☑ | ||
---|---|---|---|---|
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) Это не теория а практика. Ты можешь как угодно называть немодальные диалоги и подписку на события, только к реальному асинхронному программированию оно никакого отношения не имеет.
|
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |