Есть. А если параллельно твоей аппликухе крутится кто-то третий, и тоже требует чуть-чуть проца? Лучше сделать сразу 20 тредов, и пусть операционка их разложит как ей лучше, в том числе и неравномерно. Если она умная, это даже нисколько не затормозит процесс.Сообщение от Youss
JGr124 "Katze"
имелось ввиду "двух счетных потоков в рамках одного процесса".
Идея-то понятна, и "никаких принципиальных ограничений на распаралеливание основных вычислений" действительно может не быть. Только вот как к этому отнесутся реальные процы с реальной программой? Как бы скорость при такой схеме не упала еще больше. Впрочем, хватит ныть. Просто желаю МГ чтобы у них все получилось, ибо действительно перспективный движок сейчас извлекать прибыль от многоядерности просто обязан.
Вот, кстати, цитата по случаю:
По слухам, только следующая после Конро архитектура интел будет на 100% заточена под двухядерность, избавившись от тяжкого наследия Пентиум М. Тогда можно будет ждать эффективную работу ядер с кэшем и общими данными....ни один процессор с раздельными кэшами не смог продемонстрировать быстрый обмен данными между ядрами. Только процессоры Intel Core Duo (Yonah) и Conroe, каждый из которых обладает общим для двух ядер кэшем второго уровня, позволяют быструю одновременную работу обоих ядер с общим блоком данных, но и у них наблюдаются серьёзные ограничения в скорости работы в случаях, когда общие данные модифицируются. Таким образом, наиболее эффективное использование ресурсов двухъядерных процессоров будет происходить только при работе вычислительных потоков с различными участками памяти или с одним участком памяти, но без модификации общих данных. Также для увеличения эффективности разработчикам рекомендуется жёстко привязывать вычислительные потоки к ядрам, так как при переключении задач операционная система может менять местами потоки, что увеличивает процент кэш-промахов.
ну а чем недвухядерны те-же конро и современные атлоны?
остановиться мне-бы...
но я всю ночь летал
В новостях когда-то, были какие-то 4-х ядерные АМДшки.
А, вот, еще говорят, что проц у playstation3 рулёзный.
Even in death we shall live forever
mr_tank
Читай цитату что я привел. Современные двухядерники недвухядерны тем что каждое ядро хорошо работает само по себе, а как только требуется чтобы работали оба вместе - тут и начинаются затыки в виде медленного обмена данными и медленной синхронизации данных.ну а чем недвухядерны те-же конро и современные атлоны?
насколько медленно? решения по двухядерности у АМД и Интел малость разные.
остановиться мне-бы...
но я всю ночь летал
Ну, потери на синхронизацию всегда были, есть и будут, ибо одновременного доступа к изменяющимся данным никто и никогда не сможет обеспечить - всегда кому-то придется ждать. Тем не менее, есть уйма задач, в которых тесного взаимодействия между отдельными нитками и не требуется, и потому потерь (почти) не будет.
JGr124 "Katze"
Несомненно накладные расходы на синхронизацию неизбежны. Другое дело, что может быть за счет размещения аппаратной поддержки средств синхронизации непосредственно на кристалле, удастся снизить эти накладные расходы. Хотя бы за счет того, что эти средства уже будут работать на частоте кристалла, а не на частоте системной шины.
Тем не менее, если один поток заблокировал данные, другой нуждающийся в них поток все равно будет ждать до тех пор, пока первый не снимет блокировку. Но это уже вопрос архитектуры программы, а не аппаратных средств.
MUTbKA
В БоБе будет уйма задач, в которых "тесного взаимодействия между отдельными нитками и не требуется"?!!! Где тут пучеглазые смайлики... Что вы все время с Аерохиппи в теорию сьезжаете, мы же про конкретный продукт говорим.Тем не менее, есть уйма задач, в которых тесного взаимодействия между отдельными нитками и не требуется, и потому потерь (почти) не будет.
Крайний раз редактировалось Pbs; 07.06.2006 в 12:40.
Я рассуждаю здесь, основываясь непосредственно на своей собственной практике. Откуда такое пренебрежительное отношение к теории? Моя практика тесно связна, а точнее просто основана на теории.
Крайний раз редактировалось aeropunk; 07.06.2006 в 12:45.
![Аватар для patriot[ru]](./customavatars/avatar3376_8.gif "Аватар для patriot[ru]"){kind=avatar}
блин,2 страницы оффтопа...ну вы даёте
Cолдат всегда здоров,
Солдат на всё готов!
В.Высоцкий
Теоретикам программирования советую ознакомиться с тем, как многозадачность реализована в винде - сразу энтузиазм поугаснет.
Задача эффективного использования многопроцессорных(многоядерных) систем потребует написания своего собственного планировщика как минимум.
http://www.dtf.ru/articles/read.php?id=39888Когда я только начинал разрабатывать многопоточные приложения, мои мысли были просты и прямолинейны: нужно просто создать второй поток и выполнять в нем какую-либо работу. Потоки будут выполняться одновременно, все сложности на себя берет операционная система, мне только остается воспользоваться несколькими функциями WinAPI....
Крайний раз редактировалось AlexF; 07.06.2006 в 15:50.
Немного не в кассу пример - там изначально боролись за 10% CPU Time для одного из потоков в рамках одного процессора и двух потоков. При наличии хотя бы виртуального второго ядра (НТ) уже все становилось несколько поприятнее, хотя до идеала в виде "нужно просто создать второй поток и выполнять в нем какую-либо работу. Потоки будут выполняться одновременно, все сложности на себя берет операционная система, мне только остается воспользоваться несколькими функциями WinAPI." все равно не дотягивает
Ты статью-то дочитал до конца или остановился на простых прямолинейных мыслях?Теоретикам программирования советую ознакомиться с тем, как многозадачность реализована в винде - сразу энтузиазм поугаснет.
Задача эффективного использования многопроцессорных(многоядерных) систем потребует написания своего собственного планировщика как минимум.
http://www.dtf.ru/articles/read.php?id=39888
Крайний раз редактировалось aeropunk; 07.06.2006 в 16:21.
Я-то дочитал. И имею опыт написания многопроцессных и многопоточных приложений.
Именно поэтому и привел статью эту, а то тут именно на двух страницах флейма все было прямолинейно - разработчики чудилы не хотят под многоядерность затачивать, а ведь это так просто!
P.S. Это не значит, что этого делать не надо - за этим будущее, так что в архитектуру БоБа изначально нужно заложить многопоточность, хоть это и будет трудно и вохможно на одноядерных процах приведет к падению производительности.
Крайний раз редактировалось AlexF; 07.06.2006 в 16:43.
Здесь обсуждалось не усложнение программы, а принципиальная возможность получения выигрыша в произвоительности от многоядерных процессоров. Как и во всяком деле, здесь есть свои нюансы, которые нужно учитывать, но ничего принципиально невозможного нет.Я-то дочитал. И имею опыт написания многопроцессных и многопоточных приложений.
Именно поэтому и привел статью эту, а то тут именно на двух страницах флейма все было прямолинейно - разработчики чудилы не хотят под многоядерность затачивать, а ведь это так просто!
Да, многопоточные программы действительно гораздо сложнее однопоточных. Но соответственно работа специалистов по многоготочному программированию и оплачивается гораздо выше. Разве не так, коллега?
Ага, настолько рулезный, что выход приставки раз за разом задерживается (год задержек уже накопился или еще нет?)А, вот, еще говорят, что проц у playstation3 рулёзный.
Еще маленько про Cell:
(c) Виктор Картунов aka MatikАу, сторонники Cell, это Вам посвящается. Процессор, конечно, «антиресный», спору нет. Восемь ядер, управляющее (оно же вспомогательное) ядро, раздельная память каждого ядра, сверхбыстрые связи между ядрами…. Но кому он нужен за пределами телевизора или игровой приставки? Крутить 48 видеопотоков? Это впечатляет. Теперь бы еще понять, ЗАЧЕМ крутить 48 видеопотоков одновременно. У меня ведь всего два глаза.
Ведь кто-то должен будет перевести программное обеспечение на Cell. А в чудеса и самопроизвольное программирование я не верю. Кто за это будет платить?
Перейдем на аллегории. Меня крайне удивляет идея заменить каждого умного человека комплектом из восьми имбецилов, и одного фельдфебеля с плеткой. Умных людей вообще немного, а вот таких вот «универсальных» комплектов армия нам «наделает». Пустяковое дело. Собственно, это и есть краткое изложение парадигмы Cell.
Ну, компанию Sony понять можно: хочешь, не хочешь, а деньги зарабатывать надо. Причем не только сейчас, но и в будущем. Приставка Sony PlayStation II продается уже не слишком хорошо. Нужно обеспечивать новый рывок, а для этого нужен новый товар. Вот и получилось «я его слепила из того, что было, а потом чем было, тем и полюбила» (с) народ.
Компанию Toshiba понять тоже можно: они много чего из бытовой электроники мастерят, им программируемый относительно быстрый процессор тоже лишним не будет. Глядишь, научим телевизор рекламу распознавать, чтобы пользователь на другой канал не переключил. А то, что Cell программировать надо фактически с нуля – ну так и раньше использовались проприетарные решения, особых проблем нет.
Корпорацию IBM (вернее, ее подразделение IBM Micro Electronics) не понять в этой ситуации вообще невозможно: мало того, что они единожды разработали микроархитектуру Power 4/5, они ее еще сравнительно быстро и дешево адаптировали для Apple, производя и продавая под маркой PowerPC 970. Что самое удивительное, ее же удалось еще слегка обрезать (!), и продать по три комплекта в качестве ядра для Xbox 360. И кому – самой Microsoft! Но и это еще не все: опять слегка переделанную архитектуру удалось продать в качестве ядра общего назначения в Cell. Причем не одной компании, а сразу трем. Мелким таким островным производителям: SONY, Toshiba, NEC.
Да это уже просто праздник какой-то! (с)
Думаю, менеджмент IBM Micro Electronics в день подписания договоров отплясывал не только джигу, но и другие малоизвестные танцы.В конце концов, не каждый день одну и ту же разработку удается вначале как следует использовать самим, а затем продать на сторону ПЯТЬ раз.
Действительно, есть что отпраздновать. Ведь, кроме всего прочего, продается не интеллектуальная собственность, отнюдь. Всем этим клиентам IBM будет отгружать полноценные микросхемы, произведенные на собственном заводе. Разумеется, за скромное, но достойное вознаграждение.
Когда встречаешь столь красивые маркетинговые схемы, где-то глубоко внутри прямо-таки гордость за человечество просыпается! Мало того, что одну и ту же разработку использовали сами, заработав на ней денег, а затем продали пять раз (!), так еще и попутно свой простаивающий завод загрузили на несколько ближайших лет (а то и на более долгий срок). Что называется, могу только восхититься.
Впрочем, искренняя радость за IBM не мешает мне помнить, что к идее повседневного использования Cell (и вообще к нынешней парадигме параллельного программирования) я отношусь скорее пессимистически.
Тем паче, что выход Cell сопровождался очередной лживой маркетинговой компанией. Той самой, где процессору Cell приписывают производительность на уровне 250Gflops. Если бы. Тут SONY, Toshiba и NEC воспользовались методом Apple (которая по части лжи давно уже впереди планеты всей): берем Cell, и приводим ее производительность в неких «флопсах». Красиво получается.
Правда, некоторые «зануды» еще помнят, что «флопсы» были определены для 64-битных операций. Тогда как в процессоре Cell производительность указывается в некоторых невнятных «32-бит флопс». Потому производительность в классических «флопсах» сравнивать с «чудо - производительностью» Cell нельзя.
Просто потому, что они разные. Невзирая на 250 типа «гигафлопсов», классических гигафлопсов процессор Cell сможет обработать не 250 миллиардов, а порядка 18 (пиковая производительность). Неслабая разница? Вот то-то же.
Не верите?! А не хотите взглянуть на результаты реального тестирования производительности? Причем тестирования, проведенного самой IBM? Тут уже не спишешь на «кривые руки тестеров».
Извольте!
Все рассмотрели? Я процитирую кусочек на всякий случай: The best parallel Linpack double-precision floating-point results measured from hardware is 11.82GFLOPS.
Простите, здесь никто не встречал наших 250 «гигафлопсов»?! Где же они? Были же где-то здесь… Беда какая, нигде их не видно….
Как я уже говорил, к этому «продвинутому приему» впервые стала прибегать Apple. Видимо, яблочные маркетологи таки сумели уверовать в свой собственный девиз «Think different», и таки стали думать по-другому. Не так, как следует из Аристотелевой логики, а иначе.
Впрочем, ладно: поклонники Apple, как и все маргиналы, имеют право на причуды. Зачем им логика, это же так скучно! А вот когда три уважаемых корпорации начинают непонятные игрища с цифрами, начинаешь поневоле опасаться за их существование. Тем более что Sony в последнее время постоянно попадает в какие-то не слишком красивые истории. То с производительностью Cell цинично лгут, то выпускают музыкальные диски с защитой от копирования, фактически устанавливающие на компьютер пользователя без каких-либо вопросов специализированное ПО, больше напоминающее spyware.
Если эта полоса «удачного маркетинга» продлится, того и гляди, их Samsung обгонит. Тем более, что как раз Samsung очень не прочь обогнать всех, включая электромагнитное излучение. Он даже наметил план, краткое содержание которого можно передать словами: «и тут появляемся мы, все в белом, и побеждаем!».
Даже комментировать не хочется. Лучше про Cell вспомним.
В общем и целом, процессор Cell мне не нравится. Не верю я в революции в технике.
"Читер - это пилот, которого ты редко видишь, потому что его постоянно закрывает от тебя твоя бронеспинка" (с) 228ShAD_Romeo
ASUS P8Z68-V / Core i5-2500K / 2 x 4 Гб DDR3-1600 / 2 x Radeon HD 6970 / Win7'64
Ничего подобного тут не обсуждалось... Здесь обсуждалось аспекты работы БоБа на двух- и много-ядерных машинах. Моя позиция была - хорошо будет если хоть чем-то второе ядро загрузят, даже на 50% было бы просто супер. А вы размахнулись - под четырехядерные им оптимизацию подавай! А когда я вам стал говорить, что не только под четырехядерные, но и под двухядерные проблема прирост производительности в БоБе сделать, тут вы начали гнать пургу насчет того что мол-де в отдельных приложениях от многоядерных прирост будет обязательно. Налицо непонимание сути спора и излишнее показывание своей вумности, имхо...
ну яблочники с сантехниками уже обделывались на сервер-бенчах.
яблочники как-то демонстрировали как их сервер уделывает интел Xeon в два раз на серверении, пока не выяснилось, что тесты для себя они компили собственным оптимизирующим компилятором, а для интела пересобирали их фриварным GCC.
как только этот же тест компильнули 8-ым интелом яблоко отстало более чем в 1.5 раза.
сантехники те еще дальше пошли. выставили результаты тестов где алгоритм теста для сана заменен "полным математическим аналогом".
Господа, третья страница оффтопа. При его продолжении буду вынужден кусок темы перенести в "железо". Это намек.
Исторический консультант средней квалификации способен насмерть задолбать небольшую команду разработчиков
Лучше на оверлокерс ру перенести
Все выше изложенное не более чем скромное мое мнение и попрошу говорить на "ты".
Будь честен и справедлив! Это лечит от слабости ,глупости ... Ты достоин этого !
конфиг,выдели текст,он тут ->Коре е8400-3000мгц;ддр3 1333 8гб;звук интгр;HD 6850 1gb;вин7х64sp1 6.1.7601.Пакеты драйверов все крайние.
А что с дальностью стрельбы в БзБ? Или лазерганы форева?
Ветер будет - не будет лазерганов
не можешь летать - не мучай метлу!
Меня интересует вопрос траектории полета снаряда (пули) при появлении крена у "платформы".
Сейчас у нас снаряды летают как положено только при крене 0... при любом другом крене они тоже летают по пораболе только в вертикальной плостости строительной оси стреляющего самолета и составляющая крена не учитывается никак (Ньютон в гробу уже устал переварачиваться), всемирный закон тяготения действует в этой области с "поправками"?....
ДОКОЛЛЕ? Доколе в вираже и при скольжении будет так просто попадать???
Только пуля не ищет компромисса.
Ваши права
