|
|
|
Много поточность!
|
|||
|---|---|---|---|
|
#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 |
|
||
|
|
start [/forum/topic.php?fid=57&msg=34141911&tid=2029982]: |
0ms |
get settings: |
9ms |
get forum list: |
9ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
63ms |
get topic data: |
5ms |
get forum data: |
2ms |
get page messages: |
64ms |
get tp. blocked users: |
1ms |
| others: | 220ms |
| total: | 377ms |
| 0 / 0 |
