Имя: Пароль:
1C
1С v8
Когда-нибудь будет многопоточность?
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) Это не теория а практика. Ты можешь как угодно называть немодальные диалоги и подписку на события, только к реальному асинхронному программированию оно никакого отношения не имеет.
Компьютеры — это как велосипед. Только для нашего сознания. Стив Джобс