|
|
|
Много поточность!
|
|||
|---|---|---|---|
|
#18+
Всем удачного начала недели! Многопоточность? Как лутше организовать 12 - 20 потоков так что бы они одновременно и приблизительно с одинаковой скоростью считались? и второе при конце расчетов всех потоков выполнялось какое ли бы действие. Посоветуйте как ето лутше реализовать или где про потоки можно почитать. Программу пишу на С++ Builder 6.0. Буду очень признателен! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.11.2006, 07:25 |
|
||
|
Много поточность!
|
|||
|---|---|---|---|
|
#18+
Чтобы 20 потоков работали одновременно, надо иметь 20 процессоров. А иначе будут они работать по очереди - будут выделяться кванты времени на каждый поток. Если у потоков одинаковые приоритеты, то выполняться они будут с примерно одинаковой скоростью (если скорость мерять на интервале существенно больщем чем размер кванта времени). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.11.2006, 07:47 |
|
||
|
Много поточность!
|
|||
|---|---|---|---|
|
#18+
я это понимаю ведь всеравно так же будет быстрей чем все запускалось и делалось бы одним потоком последовательно.(теоретически) Так вот хочу спросить у тех кто знает как определить и как лутше сделать. задача матиматическая много итераций и вычислений. Данные берет с базы для вычислений ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.11.2006, 08:58 |
|
||
|
Много поточность!
|
|||
|---|---|---|---|
|
#18+
может стоит разделить не на 20 потоков а на 4 (и для этого купить тачку с 4 процами)? просто так по сути расчет одного цикла состовляет 2-3 минуты 20*3 = 60 минут если последовательно. Может кто знает нормальную документацию по потокам и как их лутше использовать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.11.2006, 09:02 |
|
||
|
Много поточность!
|
|||
|---|---|---|---|
|
#18+
по идее, на однопроцессорной машине парралельное вычисление будет медленнее последовательного. с увеличением числа процессоров разница в скорости должна уменьшаться и устремиться к нулю при устремлении числа процессоров к числу вычисляемых задач. На практике, все, конечно, будет еще хуже... Но оптимально - это количество потоков равное количеству процессоров. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.11.2006, 09:32 |
|
||
|
Много поточность!
|
|||
|---|---|---|---|
|
#18+
Несколько потоков на одном процессоре будет работать медленнее, чем один, т.к. вычисления (трудоемкость) одни и теже, скорость вычислений одна и та же, но прибавляется время на переключение потоков. Тачка на 4 процессора - вариант. Но надо знать какими средствами будет добиваться распароллеливание. Так же вариант - распределенные вычесления. Т.е. на нескольких компьютерах в сети. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.11.2006, 09:41 |
|
||
|
Много поточность!
|
|||
|---|---|---|---|
|
#18+
Но для распределенного вычесления софта сейчас мало, и, наверное, он дорогой. Так что может прийдется писать протоколы и средства самому. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.11.2006, 09:42 |
|
||
|
Много поточность!
|
|||
|---|---|---|---|
|
#18+
думал над распределенным вычислением, блин у заказчика не хватит денег на его реализацию. думаю что логично будет тогда просто создать 2 потока и между ними поделить все математические вычесления. Просто щас много пошло пней 4 а там 2 проца (один физ. второй логический). Реализовать многопоточность как я понимаю можно стандартными средствами Builderа или через WIN API. А что лутше? так вроде по теории класс TTrehead в Builder это обработанный Win API. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.11.2006, 10:05 |
|
||
|
Много поточность!
|
|||
|---|---|---|---|
|
#18+
mikola1982Может кто знает нормальную документацию по потокам и как их лутше использовать.Все вышенаписанное справедливо. Для организации отдельного потока используется класс TThread, в хелпе и Examples есть нормальные примеры. Есть ограничение на число одновременно запущенных потоков (вроде бы 12). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.11.2006, 10:09 |
|
||
|
Много поточность!
|
|||
|---|---|---|---|
|
#18+
mikola1982думал над распределенным вычислением, блин у заказчика не хватит денег на его реализацию. думаю что логично будет тогда просто создать 2 потока и между ними поделить все математические вычесления. Просто щас много пошло пней 4 а там 2 проца (один физ. второй логический). Реализовать многопоточность как я понимаю можно стандартными средствами Builderа или через WIN API. А что лутше? так вроде по теории класс TTrehead в Builder это обработанный Win API. На счет распрдеделения вычислений по процессорам, я не специалист. Здесь, ждать, что кто-нибудь другой ответит, или лазить по инету. На счет распределенных вычислений - у него отдельный комп стоит на проэект, и не включен в сетку?Т.к. в сетке как минимум 90 процентов ресурсов свободно, и отдельные машины тут не нужны. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.11.2006, 10:11 |
|
||
|
Много поточность!
|
|||
|---|---|---|---|
|
#18+
mikola1982Всем удачного начала недели! Многопоточность? Как лутше организовать 12 - 20 потоков так что бы они одновременно и приблизительно с одинаковой скоростью считались? и второе при конце расчетов всех потоков выполнялось какое ли бы действие. Посоветуйте как ето лутше реализовать или где про потоки можно почитать. Программу пишу на С++ Builder 6.0. Буду очень признателен! А в чем заключается задача? И почему нужно именно 12 (минимум) потоков? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.11.2006, 10:30 |
|
||
|
Много поточность!
|
|||
|---|---|---|---|
|
#18+
просто матиматика! Очень много итераций, умножения, возведения в степень. Можно меньше чем 12. Просто есть 12-20 алгоритмов обработки данных, которые берут с БД общую инф. производят еЁ обработку и выдают результат. Вот в принцепе и вся суть задачи. Один алгоритм выполняется от 2 до 3-х минут. Выполнятся все будет как минимум на 2-х процессорном серваке. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.11.2006, 10:50 |
|
||
|
Много поточность!
|
|||
|---|---|---|---|
|
#18+
mikola1982я это понимаю ведь всеравно так же будет быстрей чем все запускалось и делалось бы одним потоком последовательно.(теоретически) Так вот хочу спросить у тех кто знает как определить и как лутше сделать. задача матиматическая много итераций и вычислений. Данные берет с базы для вычислений Правильно думаешь.. не слушай тут никого кто говорит что будет работать медленнее согласен если провести эксперимент то два потока последовательно будут работать гораздо медленнее чем два потока вместе.. Особенности архитектуры современных микропроцессоров позволяет выполнять несколько операций за такт ( количество конвееров уже на П-III было помоему 6: 4 Int и 2 float можно посмотреть документашку могу ошибаться)... Учитывая нынешнюю многоядерность это даст еще больший прирост.. А писать программу видимо придеться используя MPI (самый лучший выбор) это библиотека можно прикрутить к VC+ вроде даже и бесплатную можно найти ... Реализвана куча вариантов MPI можно поискать как под WIN так и под Linux. Это библиотека для распределенных вычислений. Потоки это фуфло нет удобных механизмов синхронизаций рассылки другим потокам... не стоит изобретать вилосипед. В библиотеке MPI все давно уже есть при желании даже можно будет запустить и программу и на кластере если будет доступ... Распределенными вычислениями у нас занимаеться куча народу сходи на www.parallel.ru там много материала и куча ссылок на рускоязычные сайты (сайт научный но практические вещи тоже можно найти). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.11.2006, 10:51 |
|
||
|
Много поточность!
|
|||
|---|---|---|---|
|
#18+
Для двухпроцессорной системы (c поддержкой HT), я-бы сделал так: 1) Четыре рабочих потока, которые занимаются вычислениями (2 процессора * 2 логических АЛУ = 4 ). 2) Один поток диспетчер, для мониторинга за статисткикой и управлением. Он не будет потреблять много ресурсов. В основном он - ждет интервалый таймера (3-5 сек) и снимает показания с разделяемых переменных для публикации. Он же может прибивать зависнувшие потоки и ставить на выполнение новые. 3) Перед стартом - задания выстраиваются в очередь. Первые четыре стартуют сразу. Оставшиеся 8 заданий ждут освобождения слотов рабочих потоков. 4) Если вычисления интенсивно используют float point - то количество рабочих потоко нужно уменьшить до 2 (на каждом физическом процессоре - только один FPU). C уважением Lord Mayton ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.11.2006, 11:00 |
|
||
|
Много поточность!
|
|||
|---|---|---|---|
|
#18+
SilverSpyder Распределенными вычислениями у нас занимаеться куча народу сходи на www.parallel.ru там много материала и куча ссылок на рускоязычные сайты (сайт научный но практические вещи тоже можно найти). спасибо!за подсказку! ща буду искать! если вам не трудно то можете выложить сылку на конкретный ресурс по данной теме! буду очень блогодарен! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.11.2006, 11:04 |
|
||
|
Много поточность!
|
|||
|---|---|---|---|
|
#18+
mayton 4) Если вычисления интенсивно используют float point - то количество рабочих потоко нужно уменьшить до 2 (на каждом физическом процессоре - только один FPU). Батенька да вы в прошлом веке живете вот цитата с одного из сайтов (википедия называеться) Today, many CPUs/architectures have more than one FPU, such as the PowerPC 970, and processors based on the Netburst and AMD64 architectures (such as the Pentium 4 and Athlon 64, respectively.) Я бы на вашем месте почитал бы что нибудь на эту тему прежде чем так категорично заявлять ! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.11.2006, 11:06 |
|
||
|
Много поточность!
|
|||
|---|---|---|---|
|
#18+
maytonДля двухпроцессорной системы (c поддержкой HT), я-бы сделал так: спасибо за совет! В общем смысыл понятен. А вобще за сколько тактов или времени создается поток? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.11.2006, 11:08 |
|
||
|
Много поточность!
|
|||
|---|---|---|---|
|
#18+
SilverSpyderОсобенности архитектуры современных микропроцессоров позволяет выполнять несколько операций за такт ( количество конвееров уже на П-III было помоему 6: 4 Int и 2 float можно посмотреть документашку могу ошибаться)... Чем же это отличается от многоядерности? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.11.2006, 11:12 |
|
||
|
Много поточность!
|
|||
|---|---|---|---|
|
#18+
Akh SilverSpyderОсобенности архитектуры современных микропроцессоров позволяет выполнять несколько операций за такт ( количество конвееров уже на П-III было помоему 6: 4 Int и 2 float можно посмотреть документашку могу ошибаться)... Чем же это отличается от многоядерности? да как сказать, поток то один вот только в етом потоке несколько операций выполняются за раз! вот помойму всЁ отличие. тоесть несколько процов несколько потоков! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.11.2006, 11:15 |
|
||
|
Много поточность!
|
|||
|---|---|---|---|
|
#18+
SilverSpyderБатенька да вы в прошлом веке живете... Ахти! (рву седые волосы) Ну... что-ж спасибо. Кстати, а какой "камень" на "борту" у афтора? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.11.2006, 11:17 |
|
||
|
Много поточность!
|
|||
|---|---|---|---|
|
#18+
Р-4 стоит у меня! про MPI посмотрел сайт пока нечего не понять. ищу дальше. а его можно будет прикрутить к билдеру? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.11.2006, 11:24 |
|
||
|
Много поточность!
|
|||
|---|---|---|---|
|
#18+
Не знаю как работает TThread на билдере, но имхо лучше сделать на чистом WIN32 API. Ничего сложного там нет. Распараллеливание вычислений - довольно сложная штука, дамаю, максимально оптимизировать надо сами алгоритмы, не вдаваясь в реализацию тех или иных математических действий на конкретном камне. Существует много способов распараллеливания вычислений (распараллеливание циклов, например), но работает это только на специальных камнях, с векторной архитектурой вычислений. Ядро WIN2000 очень умная штука )) оно само распределит нагрузку по процессорам/ядрам если у тебя обычный проц. В Ваших задачах используется только процессор и память?? Я имею ввиду, нет ли каких запросов в удаленныю БД, или работы с сетью??? Если есть - то имеет смысл увеличивать количество потоков. Если только процессор - выше головы не прыгнешь... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.11.2006, 11:44 |
|
||
|
Много поточность!
|
|||
|---|---|---|---|
|
#18+
mikola1982 Akh SilverSpyderОсобенности архитектуры современных микропроцессоров позволяет выполнять несколько операций за такт ( количество конвееров уже на П-III было помоему 6: 4 Int и 2 float можно посмотреть документашку могу ошибаться)... Чем же это отличается от многоядерности? да как сказать, поток то один вот только в етом потоке несколько операций выполняются за раз! вот помойму всЁ отличие. тоесть несколько процов несколько потоков! Тут речь про один процессор с одним ядром и несколькими конвеерами. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.11.2006, 11:45 |
|
||
|
Много поточность!
|
|||
|---|---|---|---|
|
#18+
mikola1982 про MPI посмотрел сайт пока нечего не понять. ищу дальше. а его можно будет прикрутить к билдеру? Честно сказать не видел библотеки под него.. сам писал только под Visual Studio на MPI... и довольно давно это было сейчас не слежу за прогрессом ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.11.2006, 11:46 |
|
||
|
Много поточность!
|
|||
|---|---|---|---|
|
#18+
AkhЧем же это отличается от многоядерности? Вот что написано про самый первый пентиум: Благодаря использованию суперскалярной архитектуры процессор может выполнять 2 команды за 1 такт. Такая возможность существует благодаря наличию двух конвейеров — u- и v-конвейер. u-конвейер — основной, выполняет все операции над целыми и вещественными числами; v-конвейер — вспомогательный, выполняет только простые операции над целыми и частично над вещественными. Чтобы старые программы (для 486) в полной мере использовали возможности такой архитектуры, необходимо было их перекомпилировать. Pentium является первым CISC процессором использующим многоконвейерную архитектуру. А отличие простое от многоядерности есть такой: Механизм предсказания адресов ветвления. Применяется для сокращения времени простоя конвейеров, вызванного задержками выборки команд при изменении счетчика адреса во время выполнения команд ветвления. Для этого в процессоре используется буфер адреса ветвления BTB (Branch Target Buffer), использующий алгоритмы предсказания адресов ветвления Все понятно или надо по подровнее... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.11.2006, 11:52 |
|
||
|
Много поточность!
|
|||
|---|---|---|---|
|
#18+
maytonДля двухпроцессорной системы (c поддержкой HT), я-бы сделал так: 1) Четыре рабочих потока, которые занимаются вычислениями (2 процессора * 2 логических АЛУ = 4 ). 2) Один поток диспетчер, для мониторинга за статисткикой и управлением. Он не будет потреблять много ресурсов. В основном он - ждет интервалый таймера (3-5 сек) и снимает показания с разделяемых переменных для публикации. Он же может прибивать зависнувшие потоки и ставить на выполнение новые. 3) Перед стартом - задания выстраиваются в очередь. Первые четыре стартуют сразу. Оставшиеся 8 заданий ждут освобождения слотов рабочих потоков. Я бы к этому списку добавил нити обработки потоков ввода вывода , которые будут получать данные из фалов(или бд) писать результаты, чтобы из вычисляющих потоков по максимуму исключить ожидания ВВ. То есть в п3 в очередь становится только тот поток, для которого уже получены в память все необходимые данные для расчета . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.11.2006, 11:53 |
|
||
|
Много поточность!
|
|||
|---|---|---|---|
|
#18+
SilverSpyderВсе понятно или надо по подровнее... Здесь не так уж все и просто. С предсказаниями адресов ветвления сталкнулись при создании первых конвееров. Это, просто, очень похоже на некую "фичу" конвеера(ов). Сами же u и v конвееры, как раз похожи на 2-х ядерную архитектуру. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.11.2006, 12:13 |
|
||
|
Много поточность!
|
|||
|---|---|---|---|
|
#18+
Павел. СНе знаю как работает TThread на билдере, но имхо лучше сделать на чистом WIN32 API. Ничего сложного там нет. Распараллеливание вычислений - довольно сложная штука, дамаю, максимально оптимизировать надо сами алгоритмы, не вдаваясь в реализацию тех или иных математических действий на конкретном камне. Существует много способов распараллеливания вычислений (распараллеливание циклов, например), но работает это только на специальных камнях, с векторной архитектурой вычислений. Ядро WIN2000 очень умная штука )) оно само распределит нагрузку по процессорам/ядрам если у тебя обычный проц. В Ваших задачах используется только процессор и память?? Я имею ввиду, нет ли каких запросов в удаленныю БД, или работы с сетью??? Если есть - то имеет смысл увеличивать количество потоков. Если только процессор - выше головы не прыгнешь... WIN API я бы с удовольствием тока вот про потоки не как не могу найти нормальной документации. По обращению к БД. во время вычислений их нет. Я сначалов сЁ что нужно подымаю с БД. Хм. а вот результат пишу в таблицу. Вот не понимаю как сделать нить потока вывода из алггоритмов расчет? тоесть создать поток который бы писал в БД пока считает следующий цикл? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.11.2006, 12:15 |
|
||
|
Много поточность!
|
|||
|---|---|---|---|
|
#18+
Akh SilverSpyderВсе понятно или надо по подровнее... Здесь не так уж все и просто. С предсказаниями адресов ветвления сталкнулись при создании первых конвееров. Это, просто, очень похоже на некую "фичу" конвеера(ов). Сами же u и v конвееры, как раз похожи на 2-х ядерную архитектуру. А если не будет предсказания ветвления то и не как не задействовать конвееры... что помещать в них ??? Отделные ядра абсольно независимы друг от друга... у конвееров все таки зависимость прямая друг от друга и от кэш памяти первого уровня... Если бы все было так просто то наращивали бы количество конвееров до бесконечности (правда в GPU так и происходит ) :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.11.2006, 12:22 |
|
||
|
Много поточность!
|
|||
|---|---|---|---|
|
#18+
mikola1982 Павел. СНе знаю как работает TThread на билдере, но имхо лучше сделать на чистом WIN32 API. Ничего сложного там нет. Распараллеливание вычислений - довольно сложная штука, дамаю, максимально оптимизировать надо сами алгоритмы, не вдаваясь в реализацию тех или иных математических действий на конкретном камне. Существует много способов распараллеливания вычислений (распараллеливание циклов, например), но работает это только на специальных камнях, с векторной архитектурой вычислений. Ядро WIN2000 очень умная штука )) оно само распределит нагрузку по процессорам/ядрам если у тебя обычный проц. В Ваших задачах используется только процессор и память?? Я имею ввиду, нет ли каких запросов в удаленныю БД, или работы с сетью??? Если есть - то имеет смысл увеличивать количество потоков. Если только процессор - выше головы не прыгнешь... WIN API я бы с удовольствием тока вот про потоки не как не могу найти нормальной документации. По обращению к БД. во время вычислений их нет. Я сначалов сЁ что нужно подымаю с БД. Хм. а вот результат пишу в таблицу. Вот не понимаю как сделать нить потока вывода из алггоритмов расчет? тоесть создать поток который бы писал в БД пока считает следующий цикл? MSDN Home > MSDN Library > Win32 and COM Development > System Services > DLLs, Processes and Threads > Вот тут много про многопоточность. Только надо еще зать фичи компилера. Т.е. не рекомендуется использовать напрямую CreateThread(), если используешь RTL. Там рядом лежит и про синхронизацию. Эо тебе как раз для считывания промежуточных вычислений другим потоком. Разные потоки одного процесса работают в одном контексте. Т.Е. ты будешь обращаться к одному и тому же куску памяти из разных потоков по одинаковым адресам. Ну и скидывай данные в базу, как и хотел. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.11.2006, 12:24 |
|
||
|
Много поточность!
|
|||
|---|---|---|---|
|
#18+
SilverSpyder Akh SilverSpyderВсе понятно или надо по подровнее... Здесь не так уж все и просто. С предсказаниями адресов ветвления сталкнулись при создании первых конвееров. Это, просто, очень похоже на некую "фичу" конвеера(ов). Сами же u и v конвееры, как раз похожи на 2-х ядерную архитектуру. А если не будет предсказания ветвления то и не как не задействовать конвееры... что помещать в них ??? Отделные ядра абсольно независимы друг от друга... у конвееров все таки зависимость прямая друг от друга и от кэш памяти первого уровня... Если бы все было так просто то наращивали бы количество конвееров до бесконечности (правда в GPU так и происходит ) :) Насколько я помню, первые конвееры и не имели предсказаний. Разработчикам советывали писать программы, где меньше циклов. :) Насколько я понял получается следующая схема параллельности в составе одного компьтера: конвеерная, ядерная, процессовая. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.11.2006, 12:26 |
|
||
|
Много поточность!
|
|||
|---|---|---|---|
|
#18+
Кстати есть подозрение что Потоки всегда создаются в контексте какого-либо процесса, и вся их жизнь проходит только в его границах. ! Следовательно используя уже двух процессорную машину мы не сможе получить ускорения ... Ибо как поток опереционка оторвет от процесса и поместит на другой процессор вед потоки разделяют общую память внутри процесса ????? Неужели вы невидели тестов даже двуядерных процессоров где на многих задачах они показывали результаты хуже чем одно ядрные но более быстрые по частоте процессоры.. И вы думаете что они не используют внутри TThread... наверняка да и не один десяток... Если же на двухпроцессорной системе то только MPI или SMP Функции... как мне кажеться... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.11.2006, 12:43 |
|
||
|
Много поточность!
|
|||
|---|---|---|---|
|
#18+
mikola1982просто матиматика! Очень много итераций, умножения, возведения в степень. Можно меньше чем 12. Просто есть 12-20 алгоритмов обработки данных, которые берут с БД общую инф. производят еЁ обработку и выдают результат. Вот в принцепе и вся суть задачи. Один алгоритм выполняется от 2 до 3-х минут. Выполнятся все будет как минимум на 2-х процессорном серваке. если вы имеете дело с БД, то расспаралеливание математики вам врядли поможет, все равно база съест большею часть времени. поэтому я бы не заморачивался, ну или вытащмл чтение данных в отдельный поток... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.11.2006, 12:45 |
|
||
|
Много поточность!
|
|||
|---|---|---|---|
|
#18+
4 потока на 4 проца? имхо все равно винда все съест аффтопитезь ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.11.2006, 12:56 |
|
||
|
Много поточность!
|
|||
|---|---|---|---|
|
#18+
Имхо автор, почитайте Рихтера, например. Там много про многопоточность. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.11.2006, 12:57 |
|
||
|
Много поточность!
|
|||
|---|---|---|---|
|
#18+
SilverSpyderКстати есть подозрение что Потоки всегда создаются в контексте какого-либо процесса, и вся их жизнь проходит только в его границах. ! Следовательно используя уже двух процессорную машину мы не сможе получить ускорения ... Ибо как поток опереционка оторвет от процесса и поместит на другой процессор вед потоки разделяют общую память внутри процесса ????? В линуксах с этим проже. Можно создать гибрид :) потока и процесса, путем указания флагов, делить ли память, файловые дискрипторы и т.д. и т.п. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.11.2006, 13:14 |
|
||
|
Много поточность!
|
|||
|---|---|---|---|
|
#18+
тоесть получается что под виндой многопоточность это фикция? и не имеет не какого смысла её использовать? С базой работа минимальна и основное время занимают вычисления (проверял). Спасибо за литературу. а если запускать экземпляры? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.11.2006, 13:41 |
|
||
|
Много поточность!
|
|||
|---|---|---|---|
|
#18+
mikola1982тоесть получается что под виндой многопоточность это фикция? и не имеет не какого смысла её использовать? С базой работа минимальна и основное время занимают вычисления (проверял). Спасибо за литературу. а если запускать экземпляры? винда это сложная система, съедающаяя несколько сот процессов и потоков, добавь к ним 4 смвоих, и раздели поровну. учти к тому же, что твои потоки имеют меньший приоритет, чем потоки ОС. кстати, вот такой впрос: где-то слышал, что в ОСях используется менеджер, который за 140 (!!!) тактов переключает процесс для выполнения 6-20 (!!!) тактов. насколько это достоверно??? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.11.2006, 13:46 |
|
||
|
Много поточность!
|
|||
|---|---|---|---|
|
#18+
Aklinгде-то слышал, что в ОСях используется менеджер, который за 140 (!!!) тактов переключает процесс для выполнения 6-20 (!!!) тактов. насколько это достоверно??? В такой нотации это бред. Может это специальный системный процесс. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.11.2006, 13:55 |
|
||
|
Много поточность!
|
|||
|---|---|---|---|
|
#18+
mikola1982тоесть получается что под виндой многопоточность это фикция? и не имеет не какого смысла её использовать?Многопоточные приложения полезны если надо: 1) сохранить интерактивность во время длительных вычислений 2) при долгом обмене с железом 3) упростить архитектуру софта (иногда) mikola1982а если запускать экземпляры?Почти то же самое только на уровне ОС, но сложнее сделать синхронизацию ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.11.2006, 14:03 |
|
||
|
Много поточность!
|
|||
|---|---|---|---|
|
#18+
SilverSpyderКстати есть подозрение что Потоки всегда создаются в контексте какого-либо процесса, и вся их жизнь проходит только в его границах. У меня было другое подозрение: в Винде невозможно создать процесс с нулевым количеством рабочих потоков. А из этого следует что единицей многозадачности в Винде является именно поток а не процесс. Процесс - это как-бы логическое обьединение группы потоков. ИМХО. Помнится, где-то была статья, где аффтор очень сильно расхваливал такую модель многозадачности. По моему речь шла о сравнениях Windows и *nix. Вопрос муссировался в контексте использования разделяемой памяти. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.11.2006, 14:18 |
|
||
|
Много поточность!
|
|||
|---|---|---|---|
|
#18+
короче сделаю наверное три потока один контролирующий 2 расчет вести будут! а остольное как я понимаю зависит от винды и компилятора! главное что бы каждому потоку выделялось отдельно процессорное время, плюс можно им поставить приоретет побольше, как и самому экземпляру так и потокам. Главное что бы они сами конкурировали за время ЦП, и с другой стороны винда раздает время ЦП в зависемости от степени требования его приложением. Всетаки мне кажеться расчеты буду идти быстрей чем выполнять их последовательно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.11.2006, 14:45 |
|
||
|
Много поточность!
|
|||
|---|---|---|---|
|
#18+
SilverSpyderКстати есть подозрение что Потоки всегда создаются в контексте какого-либо процесса, и вся их жизнь проходит только в его границах. ! Следовательно используя уже двух процессорную машину мы не сможе получить ускорения ... Ибо как поток опереционка оторвет от процесса и поместит на другой процессор вед потоки разделяют общую память внутри процесса ?????Бред какой-то. Все процессоры к общей памяти обращаются. SilverSpyder Неужели вы невидели тестов даже двуядерных процессоров где на многих задачах они показывали результаты хуже чем одно ядрные но более быстрые по частоте процессоры.. И вы думаете что они не используют внутри TThread... наверняка да и не один десяток... На тех тестах, корорые используют потоки, многоядерные процессовы выигрывают. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.11.2006, 17:01 |
|
||
|
Много поточность!
|
|||
|---|---|---|---|
|
#18+
Barlone SilverSpyderКстати есть подозрение что Потоки всегда создаются в контексте какого-либо процесса, и вся их жизнь проходит только в его границах. ! Следовательно используя уже двух процессорную машину мы не сможе получить ускорения ... Ибо как поток опереционка оторвет от процесса и поместит на другой процессор вед потоки разделяют общую память внутри процесса ?????Бред какой-то. Все процессоры к общей памяти обращаются. SilverSpyder Неужели вы невидели тестов даже двуядерных процессоров где на многих задачах они показывали результаты хуже чем одно ядрные но более быстрые по частоте процессоры.. И вы думаете что они не используют внутри TThread... наверняка да и не один десяток... На тех тестах, корорые используют потоки, многоядерные процессовы выигрывают. Согласен брежу про общую память я и забыл... просто когда то работал на двухпроцессорной машине с разделяемой памятью ... вот и загнался... Если операционка WIN управляет потоком как процессом то все верно ... тут у меня серьезный бред... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.11.2006, 17:21 |
|
||
|
Много поточность!
|
|||
|---|---|---|---|
|
#18+
mikola1982тоесть получается что под виндой многопоточность это фикция? и не имеет не какого смысла её использовать?лично для меня смысл есть :) А многопотоки - не фикция, они есть, сам видел. maytonУ меня было другое подозрение: в Винде невозможно создать процесс с нулевым количеством рабочих потоков. А из этого следует что единицей многозадачности в Винде является именно поток а не процесс. Процесс - это как-бы логическое обьединение группы потоков.процессы делаются для изоляции задач в виртульной памяти, потоки - для шедулинга процессорного времени, нити - для шедулинга лапками. А в линухе как? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.11.2006, 17:54 |
|
||
|
Много поточность!
|
|||
|---|---|---|---|
|
#18+
maXmoпроцессы делаются для изоляции задач в виртульной памяти, потоки - для шедулинга процессорного времени, нити - для шедулинга лапками. А в линухе как? Минутку... минутку... вы разделяете термины поток (thread) и нить (? thread ?). Тоесть утверждаете, что это - суть разные вещи. До этого времени я так не считал. Давайте определимся, что есть что во избежание кривотолков. С уважением Mayton ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.11.2006, 18:00 |
|
||
|
Много поточность!
|
|||
|---|---|---|---|
|
#18+
Akh Aklinгде-то слышал, что в ОСях используется менеджер, который за 140 (!!!) тактов переключает процесс для выполнения 6-20 (!!!) тактов. насколько это достоверно??? В такой нотации это бред. Может это специальный системный процесс. это процесс низшего системного, самый проиритетный, но все же, тратить 140 тактов против 6-20, это распиздяйство. т.е. мы должны сохранить одни регистры, загрузить другие, и т.д. и т.п. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.11.2006, 18:43 |
|
||
|
Много поточность!
|
|||
|---|---|---|---|
|
#18+
Aklin Akh Aklinгде-то слышал, что в ОСях используется менеджер, который за 140 (!!!) тактов переключает процесс для выполнения 6-20 (!!!) тактов. насколько это достоверно??? В такой нотации это бред. Может это специальный системный процесс. это процесс низшего системного, самый проиритетный, но все же, тратить 140 тактов против 6-20, это распиздяйство. т.е. мы должны сохранить одни регистры, загрузить другие, и т.д. и т.п. согласен что ето растрындяйство! мне вот интересно как виста будет работать? А насчЁт вопроса. читая то что сдесь пишут прихожу к выводу что всЁтак и лутше делать через потоки. А количество потоков и как их лутше создовать можно узнать тока через эксперементы. Хочу сдлелать что бы он сичтал все сначало последовательно определить время, потом что бы все считалось в потоках. Результаты выложу суда. :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.11.2006, 06:27 |
|
||
|
Много поточность!
|
|||
|---|---|---|---|
|
#18+
mayton maXmoпроцессы делаются для изоляции задач в виртульной памяти, потоки - для шедулинга процессорного времени, нити - для шедулинга лапками. А в линухе как? Минутку... минутку... вы разделяете термины поток (thread) и нить (? thread ?). Тоесть утверждаете, что это - суть разные вещи. До этого времени я так не считал. Давайте определимся, что есть что во избежание кривотолков. С уважением MaytonНе, речь видимо шла про thread и fiber :) Поищите в msdn ConvertThreadToFiber, GetCurrentFiber, CreateFiber, SwitchToFiber, GetFiberData, DeleteFiber ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.11.2006, 07:56 |
|
||
|
Много поточность!
|
|||
|---|---|---|---|
|
#18+
Aklin Akh Aklinгде-то слышал, что в ОСях используется менеджер, который за 140 (!!!) тактов переключает процесс для выполнения 6-20 (!!!) тактов. насколько это достоверно??? В такой нотации это бред. Может это специальный системный процесс. это процесс низшего системного, самый проиритетный, но все же, тратить 140 тактов против 6-20, это распиздяйство. т.е. мы должны сохранить одни регистры, загрузить другие, и т.д. и т.п. Тогда его логику надо вживлять в менеджер задач, что не корректно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.11.2006, 09:48 |
|
||
|
Много поточность!
|
|||
|---|---|---|---|
|
#18+
maytonТоесть утверждаете, что это - суть разные вещи.угу, вот прогаммерам на жаве сызмальства втирают, что потоки на солярке реализованы как нити. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.11.2006, 11:10 |
|
||
|
Много поточность!
|
|||
|---|---|---|---|
|
#18+
mayton maXmoпроцессы делаются для изоляции задач в виртульной памяти, потоки - для шедулинга процессорного времени, нити - для шедулинга лапками. А в линухе как? Минутку... минутку... вы разделяете термины поток (thread) и нить (? thread ?). Тоесть утверждаете, что это - суть разные вещи. До этого времени я так не считал. Давайте определимся, что есть что во избежание кривотолков. С уважением Mayton волокна имеются в виду. есть в винде такое, многопоточность а-ля Win16 в рамках одного потока ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.11.2006, 11:23 |
|
||
|
Много поточность!
|
|||
|---|---|---|---|
|
#18+
фибры примечательны тем, что между ними можно переключаться, скажем, раз в секунду, а не раз в миллисекунду или как там ось потоки переключает... Кстати, миллисекунда - это сколько миллионов тактов? А вы 6-10... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.11.2006, 11:29 |
|
||
|
Много поточность!
|
|||
|---|---|---|---|
|
#18+
maXmoфибры примечательны тем, что между ними можно переключаться, скажем, раз в секунду, а не раз в миллисекунду или как там ось потоки переключает... Кстати, миллисекунда - это сколько миллионов тактов? А вы 6-10... Тут дело немного в другом. Насколько я понимаю если поток уходит в системый вызов который быстро обработать невозможно (например ожидание ответа от DMA), то ОС прекращает контекст нити и отдает процесср другой, готовой к выполнению. А системный вызов может произойти и на 10 такте контекста. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.11.2006, 11:55 |
|
||
|
Много поточность!
|
|||
|---|---|---|---|
|
#18+
ну... это уже совсем другие яйца. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.11.2006, 13:00 |
|
||
|
Много поточность!
|
|||
|---|---|---|---|
|
#18+
это поток сам себя прерывает ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.11.2006, 13:01 |
|
||
|
Много поточность!
|
|||
|---|---|---|---|
|
#18+
maXmoэто поток сам себя прерывает Если это невытесняющая многозадачность, то сам. Если вытесняющая то его должна прерывать ОС. Основная масса современных ОС имеют вытесняющую многозадачность. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.11.2006, 13:15 |
|
||
|
Много поточность!
|
|||
|---|---|---|---|
|
#18+
onstat- maXmoэто поток сам себя прерывает Если это невытесняющая многозадачность, то сам. Если вытесняющая то его должна прерывать ОС. Основная масса современных ОС имеют вытесняющую многозадачность. хм! ето то понятно вопрос то в другом как лутше сделать что бы работало быстрей. Как отыскать грань количества потоков которые можно создать. Ведь мало потоков создаш проц будет простаивать, создаш много проц будет не спровлятся. Может кто писал много поточные программы? Поделитесь какие трудности возникают что бы сразу же их постораться обойти. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.11.2006, 06:31 |
|
||
|
Много поточность!
|
|||
|---|---|---|---|
|
#18+
Еще раз: если основное время занимают вычисления, количество потоков должно быть равно количеству логических процессоров (с учетом моногоядерности, гипертрединга). Если ввод данных - вывод результатов требует заметного времени, потоков можно создавать больше - пока один ждет завершения ввода-вывода, другой считает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.11.2006, 09:31 |
|
||
|
Много поточность!
|
|||
|---|---|---|---|
|
#18+
mikola1982Может кто писал много поточные программы? Поделитесь какие трудности возникают что бы сразу же их постораться обойти. Не безбашенное количество потоков - дело не страшное. Ведь в системе и без ваших потоков их достаточное количество, и все же ваша программа выполняется. Тем более, если рассудить, если количество ваших потоков будет расти, то процессор будет чаще переключаться на ваши задачи. Наибольшая трудность - это найти грань между количеством времени, которое давать потоку для idle, и скоростью с которой он должен обрабатываеть данные. Дашь, много idle - другие будут чаще работать, но он будет дольше передовать данные, мало - наоборот. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.11.2006, 10:05 |
|
||
|
Много поточность!
|
|||
|---|---|---|---|
|
#18+
BarloneЕще раз: если основное время занимают вычисления, количество потоков должно быть равно количеству логических процессоров (с учетом моногоядерности, гипертрединга). Если ввод данных - вывод результатов требует заметного времени, потоков можно создавать больше - пока один ждет завершения ввода-вывода, другой считает. Я думаю немного по другому. Вычислять нужно в одних потоках, а операции ВВ и другие потенчциально тормозные прыжки на уровень ядра выносить в другие. Чтобы контекксты потоков которые занимаются вычеслением не прерывались до истечения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.11.2006, 10:06 |
|
||
|
Много поточность!
|
|||
|---|---|---|---|
|
#18+
И еще. Сейчас некоторые классы организую следующим образом. Поток в цикле вызывает некоторую функцию, которая выполняет логику потока. Это функция находится в public. Так вот, программа, использующая этот класс может сама решать, должен ли класс создавать поток. Если она будет считать, что класс может работать и в контексте потока самой программы, то, например, в конструкторе класса, она скажет, что поток создавать не надо, а сама будет дергать эту функцию. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.11.2006, 10:09 |
|
||
|
Много поточность!
|
|||
|---|---|---|---|
|
#18+
onstat-Я думаю немного по другому. Вычислять нужно в одних потоках, а операции ВВ и другие потенчциально тормозные прыжки на уровень ядра выносить в другие. Чтобы контекксты потоков которые занимаются вычеслением не прерывались до истечения.По разному может быть. Если вычисления по типу "прочитали - долго считаем - записали" (долго - значит на рассчеты уходит времени больше, чем на ввод-вывод), то наверное нет смысла. Если рассчеты короткие, может быть. Но если данные для вычислений еще не готовы (другой поток еще не успел прочитать), всё равно вычислительный поток должен встать - и еще надо эту синхронизацию организовывать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.11.2006, 10:21 |
|
||
|
|
start [/forum/topic.php?all=1&fid=57&tid=2029982]: |
0ms |
get settings: |
10ms |
get forum list: |
18ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
28ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
116ms |
get tp. blocked users: |
2ms |
| others: | 245ms |
| total: | 443ms |
| 0 / 0 |
