|
Когда-нибудь будет многопоточность? | ☑ | ||
---|---|---|---|---|
0
Маленький Вопросик
19.08.15
✎
20:07
|
Народ, хотелось бы научить обработку работать на 2 потока - когда-нибудь будет реализована такая возможность??? Как считаете???
|
|||
1
Cherokee
19.08.15
✎
20:08
|
Она уже есть. Рег задания.
|
|||
2
Александр_
Тверь 19.08.15
✎
20:08
|
Всем кому нужна такая возможность, ее уже давно используют.
|
|||
3
ДенисЧ
19.08.15
✎
20:08
|
Когда у тебя мозги включатся
|
|||
4
Fl0Mаsтер
19.08.15
✎
20:08
|
(0) Дык, а сейчас? Запустить несколько фоновых задания.
|
|||
5
badboychik
19.08.15
✎
20:12
|
(0) переходи на Java
|
|||
6
Маленький Вопросик
19.08.15
✎
20:16
|
имелось ввиду:
при работе 1 пользователя - 1 обработки - процессор грузиться не более, чем на 25% (4 ядра). |
|||
7
Cherokee
19.08.15
✎
20:17
|
(6) Так 1С же скоро выпускает собственную ОС. Вот тогда и будет.
|
|||
8
badboychik
19.08.15
✎
20:20
|
(7) А собственный телефон и планшет будут?
|
|||
9
Маленький Вопросик
19.08.15
✎
20:23
|
короче, все пофигу, я так понимаю...
|
|||
10
Sserj
19.08.15
✎
20:35
|
(9) Конечно пофигу. Хочешь загрузить 4 ядра запускай 4 сеанса и грузи на здоровье :)
|
|||
11
vde69
19.08.15
✎
20:36
|
||||
12
su_mai
19.08.15
✎
20:38
|
(0) Какую конкретно задачу решаешь?
|
|||
13
Маленький Вопросик
19.08.15
✎
20:39
|
(12) загрузка документов
|
|||
14
Маленький Вопросик
19.08.15
✎
20:40
|
(11) вот, интересная вещь
|
|||
15
su_mai
19.08.15
✎
20:41
|
(13) зачем тебе многопоточность?
|
|||
16
Злопчинский
19.08.15
✎
22:29
|
||||
17
floody
19.08.15
✎
23:16
|
Про фоновые задания уже было?
|
|||
18
Котокот
20.08.15
✎
00:18
|
(0) У тебя через веб сервер подключение и поэтому на 25 только загружается проц?
|
|||
19
Провинциальный 1сник
20.08.15
✎
06:24
|
(13) При многопоточной загрузке будешь постоянно упираться в блокировку, а это надо?
|
|||
20
Лодырь
20.08.15
✎
06:31
|
(19) Можно грузить в различных потоках различные сегменты данных, которые почти не пересекаются или слабо пересекаются.
|
|||
21
VladZ
20.08.15
✎
06:44
|
(0) Никогда. Ибо нефиг!
|
|||
22
VladZ
20.08.15
✎
06:46
|
При загрузке документов можно распараллеливать работу под разными пользователями. Выгружаешь кусками и загружаешь кусками. Про блокировку уже тут написали.
|
|||
23
magicSan
20.08.15
✎
06:53
|
Что даст загрузка документов под несколькими пользователями? Вы что пологаете основной тормоз это перадача данных 1с sql? тормоз sql при записи. так что хоть один сеанс хоть 10 разницы никакой.
|
|||
24
Матиус
20.08.15
✎
07:56
|
(8) В девятой версии
|
|||
25
H A D G E H O G s
20.08.15
✎
07:58
|
||||
26
dmpl
20.08.15
✎
08:08
|
(0) Нет, не будет. Квалификация большинства программистов 1С слишком низкая для нормальной разработки многопоточных приложений.
|
|||
27
dmpl
20.08.15
✎
08:09
|
(15) Как зачем? Чтобы на дедлок нарваться.
|
|||
28
dmpl
20.08.15
✎
08:10
|
(20) А если они в плане обмена все?
|
|||
29
magicSan
20.08.15
✎
08:58
|
(25) ну и бред.
|
|||
30
Ненавижу 1С
гуру
20.08.15
✎
09:03
|
сервер многопоточен, клиенту это не надо, имхо
|
|||
31
Фрэнки
20.08.15
✎
09:18
|
смешались в кучу кони, люди... а ведь всего лишь про многопоточность спросил...
А что это вообще "многопоточность" - топикстартер об этом знает? |
|||
32
Фрэнки
20.08.15
✎
09:20
|
(30) не совсем так, а точнее: не весь код, исполняемый в контексте Сервер многопоточен. Даже хуже того, весь 1С:код вообще нигде не многопоточен.
|
|||
33
H A D G E H O G s
20.08.15
✎
09:25
|
(29) где бред?
|
|||
34
H A D G E H O G s
20.08.15
✎
09:27
|
Клиент вполне себе многопоточен.
|
|||
35
vde69
20.08.15
✎
09:29
|
(32) эммммммм а как-же работает кластер серверов 1с ???
ну и если быть честными то у сервера рхостов может быть много и все они работают параллельно (многопоточно). Правда не рамках разных сесий :) |
|||
36
Фрэнки
20.08.15
✎
09:39
|
(35) то, что вы видите параллельно запущенные процессы в списке _процессов_ - это в самом деле _процессы_
Многопоточность внутри процесса и она не видна в списке. Многопоточность можно было бы увидеть, если бы в один момент времени процесс выполнялся на нескольких ядрах в несколько потоков. Гораздо проще, во всех отношениях, не пытаться запараллелить, а стартовать новые сеансы в новые процессы, которые будут отрабатывать и самоликвидироваться по завершению своего исполнения. Это я все на опыте своего давнишнего программирования на С++ испытывал, когда еще 1С-кой только шабашил, а на основной работе только С++ занимался. |
|||
37
Фрэнки
20.08.15
✎
09:53
|
(35) работающие параллельно процессы - это еще не означает, что все процессы исполняются многопоточно. Каждый исполняемый процесс загружает только одно ядро, которое ему выдал планировщик.
Да и очень простой аргумент - если у нас открыта неким процессом транзакция на обработку данных (операции ввода-вывода) для какого-то количества таблиц, то обработка исполняемого кода в этой транзакции в любом случае должна завершиться один раз раз в точке фиксации транзакции. Как можно многопоточить одну транзакцию? А несколько отдельных разных транзакций можно выполнить просто в разных процессах (с разными сеансами, например). Что и делается при выполнении фоновых заданий, например. И мы можем увидеть на списке сеансов в "Консоль управления (ММС)", что каждый раз фоновые задания действительно запускаются в разных сеансах - там даже порядковые номера этих сеансов выводятся. |
|||
38
dmpl
20.08.15
✎
09:55
|
(37) Вот сейчас глянул - у клиента 1С 7 потоков запущено ;)
|
|||
39
Фрэнки
20.08.15
✎
09:55
|
37+ * Каждый исполняемый процесс загружает только одно ядро - это в случае 1С
|
|||
40
H A D G E H O G s
20.08.15
✎
09:55
|
(37) Многопоточить одну транзакцию не надо :-) Нужно многопоточить разные транзакции.
|
|||
41
Фрэнки
20.08.15
✎
09:56
|
(38) ну да, потоки как бы есть - для морды клиента
|
|||
42
Фрэнки
20.08.15
✎
09:57
|
(40) не многопоточить, а параллелить - так будет ближе в англоязычной терминологии
|
|||
43
Фрэнки
20.08.15
✎
10:01
|
(38) самое простое в использовании потоков - зацеплять новые потоки за каждым новым фреймом. Эти фичи уже давно сидят в библиотеках.
|
|||
44
magicSan
20.08.15
✎
10:01
|
(36) Хоть кто то что то понимает
|
|||
45
magicSan
20.08.15
✎
10:03
|
(44) В рамках 1С впрочем большинство подгоняет это под то что разные процессы кластера грузятся. Что впрочем почти тоже самое. Я тока понять не могу для каких задачь эта хрень. Если основная нагрузка на запись данных, где рулит sql и он сам по себе многопоточен.
|
|||
46
magicSan
20.08.15
✎
10:03
|
(45) *хрень=(0)
|
|||
47
dmpl
20.08.15
✎
10:04
|
(40) Вообще, в рамках задачи по загрузке объектов (в случае если он упирается в ЦП) надо параллелить только подготовку объекта в памяти, а затем передавать его отдельному потоку, который и пишет в транзакцию. Вот на этом этапе у 1Сников и возникает вынос мозга, а потому нет смысла давать им гранату.
|
|||
48
ILM
гуру
20.08.15
✎
10:05
|
(44) Частицы "то", "либо", "нибудь", "таки", "да" - пишутся через дефис. Например: Кто-то, что-то, когда-нибудь и т.д.
(45) И перед что ставится запятая внутри предложения. |
|||
49
За1СьЭтотМир
20.08.15
✎
10:17
|
(45) Заносить данные в регистр по разным измерениям. Или в разные регистры.
Без многопоточности. 1. Делаем запись в первый регистр , или по одному измерению. 2. Ждем. 3. Записываем новый блок данных. С многопоточностью. 1. Первый блок данных. 2. Второй блок данных. .... Я так понимаю. |
|||
50
Фрэнки
20.08.15
✎
10:19
|
(43) Кстати, вспоминается мне сейчас: вот эта самая многопоточность, даже если она в программистком смысле уже задействована внутри процесса, то самое, что показывает список процессов, что потоки запущены - этим потокам на низком уровне планировщиком должна быть назначены собственные адресные пространства в оперативе, какие-то там дескрипторы и т.д. и т.п., а уже затем, при обеспечении полной(!) _изоляции_ одного потока от своего соседнего внутри(!!) общего породившего их процесса, будет возможна передача исполнения потока на параллельно доступное(!!!) ядро.
Так вот, проблема планировщиков заданий у современных операционных систем в том, что большинству существующих приложений они не могут выдавать доступ к нескольким ядрам одновременно одному процессу. Из-за плохой изоляции данных разных потоков между собой. Но все-таки известны примеры приложений, которым удается реализовать на практике многопоточность с параллельной загрузкой нескольких ядер. Самое популярное такое приложение - это MS SQL |
|||
51
magicSan
20.08.15
✎
10:22
|
(48) Включи ассоциативное мышление возможно начнешь понимать написаное без черточек
|
|||
52
magicSan
20.08.15
✎
10:25
|
(49) Два процесса пишут в одну и туже таблицу, в итоге передавая управление sql. У нас что тормоза на уровне передачи данных в sql?
|
|||
53
Кирпич
20.08.15
✎
10:27
|
(0)(13) Ну запусти еще один сеанс да загружай себе. Все равно время загрузки будет одинаковое при одном потоке или при десяти. В один поток даже быстрее будет, не будет байды с блокировками. Диск то у тебя один и кабель сетевой тоже один. Короче иди работай.
|
|||
54
За1СьЭтотМир
20.08.15
✎
10:29
|
(52) Ну смотри . Допустим, пишем 2а набора в разные регистры.
Код : Набор1.Записать() Ждем записи.... Набор2.Записать() А так это одновременно будет происходить. |
|||
55
vde69
20.08.15
✎
10:29
|
(50) 64х сервер 1с вполне себе умеет из одного потока загружать все ядра сервера.... именно по этому 1с рекомендует только 1 рхост....
да и вообще множество рхостов в 1с - появилось не из-ла неумения грузить процы а из-за ограничения памяти |
|||
56
Гёдза
20.08.15
✎
10:30
|
(55) Это ты сам придумал???
|
|||
57
Гёдза
20.08.15
✎
10:31
|
Ты путаешь процесс и поток
|
|||
58
Провинциальный 1сник
20.08.15
✎
10:31
|
(55) При чем тут 64?
|
|||
59
dmpl
20.08.15
✎
10:31
|
(50) Ой, да ладно. На раз-два делается.
|
|||
60
Кирпич
20.08.15
✎
10:32
|
(58) это чтобы ересь умнее выглядела
|
|||
61
magicSan
20.08.15
✎
10:34
|
(54) Это понятно. Непонятно приминительно к какой задаче это. к тому же как уже говорили в другой ветке просто запускаешь разные сеансы по разным видам документов (запись без проведения). Только вот писать надо сразу в sql, а так это всё игрушки.
|
|||
62
За1СьЭтотМир
20.08.15
✎
10:35
|
(61) В загрузке документов смысла,наверное, нет.
|
|||
63
Фрэнки
20.08.15
✎
10:36
|
(59) могу только озвучить дополнительно, что это все имхо - причем, в лурковской расшифровке этой аббревиатуры
з.ы. Не могу отнять у людей права на высказывание своего имхо :) |
|||
64
rs_trade
20.08.15
✎
10:37
|
Ответ в первом посте. Все остальное бред какой то. Если по блокировкам не пересекаются данные, дели на 2-3 части и запускай в фоновых заданиях. На больших объемах будет ускорение процентов на 40-60. Какие нафиг скуэли и рпхосты.
|
|||
65
Кирпич
20.08.15
✎
10:49
|
(64) а ты пробовал? откуда 40-60 процентов взял?
|
|||
66
rs_trade
20.08.15
✎
10:53
|
(65) Пробовал. Наибольший прирост дают 2-3 задания. Писал в справочник много элементов параллельно, документы грузил, не помню уже точно, выгружал что то. Это все тестовые задачи были на которых изучал я как раз фоновую параллельность эту.
|
|||
67
qwerty2469
20.08.15
✎
11:28
|
Например задача: нужно отсортировать по порядку огромнный массив, используя многопоточность. Как это сделать на клиенте.
|
|||
68
МихаилМ
20.08.15
✎
11:32
|
(67)
написать вк. 1с не предназначена для таких задач. |
|||
69
rs_trade
20.08.15
✎
11:33
|
(67) делишь данные например на две части, запускаешь асинхронно фоновые задания каждый со своим куском данных, в цикле ждешь отработки заданий, сливаешь по алгоритму результат.
|
|||
70
qwerty2469
20.08.15
✎
11:38
|
(69) Но фоновое задание это процесс, а не поток. И к тому же выполняется на стороне сервера, а я спрашивал на клиенте.
|
|||
71
Кирпич
20.08.15
✎
11:41
|
(67) в 1с не бывает огромных массивов. вместо огромных массивов в 1с есть "память закончилась"
|
|||
72
rs_trade
20.08.15
✎
11:41
|
(70) тебе надо быстро обработать массив данных или повы...ваться? кто на клиенте это делает, да еще и в 1с?
|
|||
73
rs_trade
20.08.15
✎
11:43
|
не предметный разговор. многопоточная сортировка на клиенте в 1С... че за бред.
|
|||
74
Гёдза
20.08.15
✎
11:43
|
(66) Зависит от многих параметров. И в первую очередь от скорости дисков.
На ССД например очень хорошо параллелится запись, на обычных практически нет |
|||
75
H A D G E H O G s
20.08.15
✎
11:51
|
(72) Я, например, это делаю, и не считаю это чем-то плохим.
|
|||
76
rs_trade
20.08.15
✎
11:51
|
(74) при одинаковых условиях. на 5 потоков поделишь, не сильно быстрее будет чем в 2-3. не в пять раз быстрее. на 10 поделишь еще и медленней будет. издержки видимо влиять начинают.
|
|||
77
qwerty2469
20.08.15
✎
11:51
|
(73) Сортировка массивов, используя многопоточность, это стандартная задачка в учебниках по программированию. Я и привел этот пример. Конечно может на практике он и ни кому не нужен.
|
|||
78
H A D G E H O G s
20.08.15
✎
11:51
|
(75) Но на практике это нахер не нужно.
|
|||
79
H A D G E H O G s
20.08.15
✎
11:52
|
(69) И залюбишься ждать результата.
|
|||
80
H A D G E H O G s
20.08.15
✎
11:53
|
Все разговоры о многопоточном клиенте закончаться ровно тогда, когда 1С реализует метод ДокументОбъект.НачатьЗапись()
|
|||
81
Фрэнки
20.08.15
✎
12:03
|
(77) в задачках по программированию многопоточность есть. Но не факт, что эти задачки на низком уровне используют несколько ядер или процессоров.
|
|||
82
qwerty2469
20.08.15
✎
12:04
|
(81) Согласен, что не факт. Но все же будет быстрее, если запустить на 1 потоке.
|
|||
83
Кирпич
20.08.15
✎
12:27
|
создал два справочника. создал два фоновых задания для добавления 10000 записей. запустил оба задания. сначала выполняется первое, потом второе. ничо не понял. похоже эти задания добавляются в очереди и выполняются последовательно в порядке очереди.
|
|||
84
Кирпич
20.08.15
✎
12:44
|
+(83) так что про 40-60% прироста производительности в (64) высосано из пальца похоже.
|
|||
85
magicSan
20.08.15
✎
12:46
|
(80) хахахахаха
|
|||
86
rs_trade
20.08.15
✎
12:55
|
(83) они асинхронно должны запускаться.
|
|||
87
ДенисЧ
20.08.15
✎
12:56
|
(83) Резиновую кияночку подарить?
|
|||
88
Живой Ископаемый
20.08.15
✎
13:01
|
2(86) ну они асинхронно запустились. сначала одно, потом асинхронно второе
|
|||
89
magicSan
20.08.15
✎
13:06
|
(88) ааааааааааааахахахаах )))) да что за юмор ветка .. )))
|
|||
90
Кирпич
20.08.15
✎
13:08
|
(86) да они тупо в очередь добавляются и выполняются по очереди параллельно с основным потоком. так что больше двух потоков не получается.
|
|||
91
Кирпич
20.08.15
✎
13:11
|
(89) укурился чтоли
|
|||
92
Фрэнки
20.08.15
✎
13:26
|
(82) Почему два потока в процессе на одном ядре будут быстрее, чем просто один процесс на таком же одном ядре?
Тут даже логика подсказывает, что на два потока будет еще и больше затрат ресурсов на постоянное переключение ядра с одного потока на другой. Возникает вопрос общей применимости многопоточности. В чем практическая выгода многопоточности, даже если в распоряжении процесса имеется только одно ядро? В расчетных задачах или в дисковых операциях - выгоды не будет. В обслуживании многооконного интерфейса выгода будет: - в передаче управления на несколько окон параллельно - в отображении/прорисовке нескольких окон параллельно. |
|||
93
rs_trade
20.08.15
✎
13:28
|
загугли уже пример.
|
|||
94
magicSan
20.08.15
✎
13:40
|
(92) Не так - пока один висит, второй будет работать. Отсюда при зацикливание ось не вешается, а продолжает работать.
|
|||
95
Кирпич
20.08.15
✎
13:42
|
почитал ИТС. Понятно теперь. Короче, в клиент-серверном варианте будет работать несколько фоновых заданий параллельно, а в файловой базе будет выполнятся последовательно.
|
|||
96
mistеr
20.08.15
✎
14:00
|
(80) Поясни, пожалуйста.
|
|||
97
H A D G E H O G s
20.08.15
✎
14:11
|
(96) Пользователь нажал кнопку Провести, форма документа стала недоступной, но управление передалось пользователю.
|
|||
98
H A D G E H O G s
20.08.15
✎
14:14
|
(96) Но основная проблема в том, что работа с интерфейсом 1С, с GUI синхронна. Исторически скорее всего так.
Как только начинает выполняться код 1С, интерфейс пользователя становится недоступным. При этом - мы прекрасно можем выполнять код 1С в отдельном (своем, неучтенном 1С) потоке (например во внешней компоненте) до тех пор, пока не трогаем интерфейс. Как только трогаем интерфейс - 1С как минимум ловит глюки интерфейса, как максимум - валится. |
|||
99
ДенисЧ
20.08.15
✎
14:16
|
(98) фоновое выполнение отчётов в бсп ты не рассматривал?
|
|||
100
Живой Ископаемый
20.08.15
✎
14:24
|
2(99) Ну вот а почему так не сделать с документами - непонятно.
|
|||
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) Это не теория а практика. Ты можешь как угодно называть немодальные диалоги и подписку на события, только к реальному асинхронному программированию оно никакого отношения не имеет.
|
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |