Windows 32-bit. Windows 64-bit. Двуядерные компьютеры. , Юзает ли в полную силу Windows 32-bit Два ядра - процессора.

Привет
Вот мы тут с AndNot'ом в ПМ спорили, и решили создать тему, что бы, кто-нибудь более знающий, рассказал как оно на самом деле. Я почему-то уверена, что 32 битная ОС не сможет вполную силу заюзать два ядра процессора.
Ещё в споре возник спор , а нужны вообще 64 битные компы
В общем обсуждаем, вот выдержки из ПМ .
Катенька

Цитата

А ты какую систему будешь устанавливать или уже установил, 64 битную ?

AndNot

Цитата

Да на кой Хафф она мне нужна? Мне и старенькой 32-х разрядной хватает

Катенька

Цитата

а она разве сможет все возможности 64 битного проца использовать, - вот на эту тему я бы хотела с тобой поговорить. А там разве есть менеджер распаралеливания процессов. В общем по моему все прелести и ПО 32 битная не сможет использовать, понятное дело проги, которые пишешь можно заюзать два проца, а вот стандартные если не 64 битные то увы только один проц

AndNot

Цитата

32-х битный режим шустрее А использование многопроцессорных систем идет еще со времен Windows NT Так что все путем

Катенька

Цитата

Как это шустрее понимать ? Если у меня рендеринг идёт плюс игра запущена музыка играет качается из инета из сети из торрента ну и всякого по немногу, например То один проц с этим не справится а два, да. Проверено, так что не спорь Или ты что-то другое имел ввиду шустрее? И насчёт двух процов и 64 битной системы ты бы не мог обьяснить ? А Зачем тогда 64 битные системы ПОмоему всё таки два ядра не могут заюзатся по крайней мере не на всю

AndNot

Цитата

Рендеринг к разрядности процессора отношения не имеет, у видюх свой GPU Но возьмем простую графику, без ускорителя. Так вот, формат пикселя составляет 24-ре бита, иногда используют еще 8-мь бит для альфа-наложения. Итого - 32 бита. К тому же каждая компонента цвета(Red, Green, Blue) обрабатываются по отдельности, так что вообще приходим к 8-ми битным вычислениям, соответственно 64-х разрядный режим здесь как пятое колесо в телеге, только мешаться будет
Теперь звук. Когда то он оцифровывался по 8-ми разрядной шкале. Потом, для повышения качества, стали выпускать звуковухи с 16-ти разрядными ЦАП и АЦП, сейчас - максимум 24-х битные. Опять 64-х разрядный режим лесом идет, особенно если звуковуха 16-ти разрядная
Что касается сокетов. Для обработки данных(компрессия, коррекция ошибок) стараются использовать MMX, на крайняк идут вычисления побайтно, через процессор (а как иначе, байт - самая малая величина данных). Так что и здесь нафих большая разрядность не нужна, к тому же 64-х битный режим передачи еще не изобрели
А теперь открою страшную тайну И в графике и в обработке звука, основная нагрузка ложится на MMX, в 3Д-графике еще и на SSE. А процессор? А он выполняет вспомогательные функции (счетчик циклов например), и соответственно до фонаря его разрядность, и 32-х бит за глаза хватает, еще и остается

Цитата

Цитата

Проверено, так что не спорь Или ты что-то другое имел ввиду шустрее?

Видишь ли, программ, где действительно нужны 64-х битные вычисления, крайне мало, наверное одна на миллион Да и в этих программах, на сами вычисления приходится доля процентов кода. А остальное - код, который вполне мог работать и на 32-х битах. И все бы ничего, но вот посмотри:

mov eax, [mem32]
add [mem32], eax

вполне обычный код. А теперь представь, что в 64-х битных прогах вместо mem32 используется mem64 И вопрос - на сколько они прожорливее к памяти? Но и это не все, здесь есть один крайне неприятный момент - кэш не резиновый. В 64-х разрядном режиме в него уместится меньше данных, нежели в 32-х разрядном. А мне ли тебе говорить, что кэш-промахи могут затормозить прогу в несколько раз! В чем я уже убеждался, и не раз, даже на этом форуме

Цитата

А Зачем тогда 64 битные системы

почитай, на WASM.RU, статью - Деструктивный маркетинг Там и есть ответ - это модно! Вот и все

Цитата

ПОмоему всё таки два ядра не могут заюзатся по крайней мере не на всю

Зря сомневаешься Видиш ли, системе совершенно до фонаря, какой режим - 32-х или 64-х битный И когда я изучал сокеты (помнишь было дело? ), то нашел интересные примеры, как программа может сама, принудительно, задействовать все имеющиеся процессоры, а может и отдать все на откуп системе

Катенька

Цитата

Цитата

Рендеринг к разрядности процессора отношения не имеет, у видюх свой GPU

да, про это я что-то, совсем забыла Но всё равно когда идёт рендеринг ЦП тоже учавствует.

Цитата

Цитата

Но возьмем простую графику, без ускорителя. Так вот, формат пикселя составляет 24-ре бита, иногда используют еще 8-мь бит для альфа-наложения. Итого - 32 бита. К тому же каждая компонента цвета(Red, Green, Blue) обрабатываются по отдельности, так что вообще приходим к 8-ми битным вычислениям, соответственно 64-х разрядный режим здесь как пятое колесо в телеге, только мешаться будет

согласна Правда распараллеливание, всё же ты не упомянул мы сможем выполнять два процесса, а здесь только один

Цитата

Цитата

Теперь звук. Когда то он оцифровывался по 8-ми разрядной шкале. Потом, для повышения качества, стали выпускать звуковухи с 16-ти разрядными ЦАП и АЦП, сейчас - максимум 24-х битные. Опять 64-х разрядный режим лесом идет, особенно если звуковуха 16-ти разрядная

А быть может ты имеешь ввиду 64-разрядный... хотя может это я не правильно понимаю, просто я думала что два проца то есть ядра в одном проце и получается два ядра по 32 разряда, вот, а ты говоришь про 64 разряда

Цитата

Цитата

Что касается сокетов. Для обработки данных(компрессия, коррекция ошибок) стараются использовать MMX, на крайняк идут вычисления побайтно, через процессор (а как иначе, байт - самая малая величина данных). Так что и здесь нафих большая разрядность не нужна, к тому же 64-х битный режим передачи еще не изобрели

к тому же 64-х битный режим передачи еще не изобрели это пожалуй ключевое

Цитата

Цитата

А теперь открою страшную тайну И в графике и в обработке звука, основная нагрузка ложится на MMX, в 3Д-графике еще и на SSE.

для меня это не тайна А процессор? А он выполняет вспомогательные функции (счетчик циклов например), и соответственно до фонаря его разрядность, и 32-х бит за глаза хватает, еще и остается Странно, кстати разве только счётчик, в том же рендеренге ?

Цитата

Цитата

Видишь ли, программ, где действительно нужны 64-х битные вычисления, крайне мало, наверное одна на миллион Да и в этих программах, на сами вычисления приходится доля процентов кода. А остальное - код, который вполне мог работать и на 32-х битах. И все бы ничего, но вот посмотри:

я думаю здесь уже не разрядности ЦП дело, а в шине

Цитата

Цитата

А теперь представь, что в 64-х битных прогах вместо mem32 используется mem64 И вопрос - на сколько они прожорливее к памяти?

да согласна.

Цитата

Цитата

Но и это не все, здесь есть один крайне неприятный момент - кэш не резиновый.

Цитата

В 64-х разрядном режиме в него уместится меньше данных, нежели в 32-х разрядном.

ну про кэш сложно говорить, так как его там тоже добавленно и не мало в отличае от предыдущих процов.

Цитата

Цитата

А мне ли тебе говорить, что кэш-промахи могут затормозить прогу в несколько раз! В чем я уже убеждался, и не раз, даже на этом форуме

сказать не лишнее

Катенька

Цитата

А зачем, тогда вообще 64 разрядные системы ?

Цитата

Цитата

почитай, на WASM.RU, статью - Деструктивный маркетинг Там и есть ответ - это модно! Вот и все

да это точно - вот про это можешь и не говорить Теперь я и сама понимаю, правда быстрее всё же работает, просто ты смотришь на это как мне кажется на уровне ассемблера

Цитата

Цитата

Зря сомневаешься Видиш ли, системе совершенно до фонаря, какой режим - 32-х или 64-х битный И когда я изучал сокеты (помнишь было дело? ), то нашел интересные примеры, как программа может сама, принудительно, задействовать все имеющиеся процессоры, а может и отдать все на откуп системе

ну это XP я так понимаю, но всё равно незнаю, почему то у меня очень большие сомнения

Следует отметить что двухядерный процессор - это просто два процессора в одном кристалле.
Любая нормальная 32 битная система в любом случае юзает в полную силу все ядра (ведь они же ещё бывают 4 ядерные, 8 ядерные), про Win2000 я не уверен, а WinXP и Win2003 точно юзает все ядра (процессоры) на полную силу. все фишки по использовнванию двуядерности (четырёхядерности и т.д.) так же есть в 32-х битном режиме, да и это больше зависит от самой операционной системы.
все 32-х битные программы, которые которые запускаются на Win64, запускаются в режиме совместимости и всё равно они работают быстрее, не на много, но быстрее. В 64 битном режиме вычисления происходят быстрее, даже у тех программ которые работают в режиме совместимости, и это факт.
про прожороливость памяти я не согласен: в 64 битном режиме размер операнда по умолчанию 4 байтовый.

Цитата

вполне обычный код. А теперь представь, что в 64-х битных прогах вместо mem32 используется mem64 И вопрос - на сколько они прожорливее к памяти?

просто адрес расширится нулями до 64 бит, а размер операнда останется таким же, вот и всё!

Сообщение отредактировано: Ahilles - 26.01.08, 05:53

Цитата Ahilles @ 26.01.08, 05:49

это просто два процессора в одном кристалле.

точнее ты хотел сказать, два ядра, так как процессор - один

Цитата Ahilles @ 26.01.08, 05:49

(ведь они же ещё бывают 4 ядерные, 8 ядерные

это уже ближэе к суперЭВМ а на них "такое" как Виндовс не ставят

Цитата Ahilles @ 26.01.08, 05:49

все 32-х битные программы, которые которые запускаются на Win64, запускаются в режиме совместимости и всё равно они работают быстрее, не на много, но быстрее. В 64 битном режиме вычисления происходят быстрее, даже у тех программ которые работают в режиме совместимости, и это факт.

так всё таки быстрее в 64 битной винде ?

Просто в начале ты сам себя опровергаешь или это я не так поняла

Цитата Ahilles @ 26.01.08, 05:49

Любая нормальная 32 битная система в любом случае юзает в полную силу все ядра

Просто то, что все ядра она использует это понятно, и то Винда же эмулирует многое и то что она использует два ядра тоже можеи с эмулировать Как например диспетчер задач, который показывает загруженность двух ЦП

Ладно, изложу по порядку, что я имею против 64-х разрядных систем.
Первый аргумент сторонников 64-х бит - адресация памяти за предел 4Гб. Не аргумент, поскольку лимит в 4Гб(для 32-х разрядных систем) явно надуман, каждой задаче доступно 64 Терабайта виртуальной памяти, единственное ограничение - предел сплошного участка памяти в 4Гб, но разве это проблемы? Это ограничение обойти легче, чем отнять у ребенка конфету
Второй аргумент. За одну операцию обрабатывается вдвое больший кусок данных, т.е. не 32, а 64 бита. Сомнительное преимущество. 64-х битная арифметика используется крайне редко, это скорее исключение, нежели правило. Там где она необходима, есть неплохие альтернативы, даже не одна.
Третий аргумент. Большее количество регистров. Против этого ничего не имею против. Но практика показывает, что этим преимуществом пользуются немногие. Особенно это касается самой XP Pro x64, которая, по большей части, 32-х разрядная (смешно, правда?), а Висту я и под стволом ставить не буду.

Цитата Ahilles @ 26.01.08, 05:49

все 32-х битные программы, которые которые запускаются на Win64, запускаются в режиме совместимости и всё равно они работают быстрее, не на много, но быстрее.

Самовнушение? Они не могут работать быстрее, даже теоретически.

Цитата Ahilles @ 26.01.08, 05:49

про прожороливость памяти я не согласен: в 64 битном режиме размер операнда по умолчанию 4 байтовый.

Неужели? А что получишь вот с такого кода:

long a1[1000];
int *a2[1000];
struct foo {
int a1;
long a2;
*char b;
int a3;
};

Немало программ, перенесенных на 64-х битную платфору, стали работать медленнее, поскольку из-за вышеприведенного кода значительно ухудьшилась работа кэша, сами проги стали жрать больше памяти, которой и так много не быват.
Так какой же смысл ставить 64-х разрядную систему?

Цитата AndNot @ 26.01.08, 15:46

Первый аргумент сторонников 64-х бит - адресация памяти за предел 4Гб. Не аргумент, поскольку лимит в 4Гб(для 32-х разрядных систем) явно надуман, каждой задаче доступно 64 Терабайта виртуальной памяти, единственное ограничение - предел сплошного участка памяти в 4Гб, но разве это проблемы? Это ограничение обойти легче, чем отнять у ребенка конфету

Интересно послушать, каким образом...

Тем же самым, каким обходили ограничения в 64Кб, при работе с большими массивами, или при работе с VESA, так же как и в 16-ти битном защищенном режиме, поскольку приращение сегмента/селектора фиксировано и известно. Ничего сложного. Но есть и более простой путь, сменить алгоритм программы, сделав ненужным использование таких больших массивов, что вполне реально и делалось во времена ДОСа. Или сделать обращения к массивам групповыми, это позволит лишь один раз, за операцию, вычислять нужный селектор, а дальше потерь производительности не будет, поскольку можно точно расчитать, когда инкрементировать сегментный регистр. Так что выбор есть
Впрочем, к ХРюну это не относится, его менеджер памяти примитивен и не умеет работать с более чем 4Гб памяти (точно не помню, но вроде 4), так что можно спать спокойно

Цитата Катенька @ 26.01.08, 14:42

точнее ты хотел сказать, два ядра, так как процессор - один

я именно хотел сказать что два процессора находящихся в одном кристалле.

Цитата Катенька @ 26.01.08, 14:42

это уже ближэе к суперЭВМ а на них "такое" как Виндовс не ставят

не правда, пожалуйста серийный проц с четырьмя ядрами - Core 2 Quad Q6600

AndNot, вот последнее предложение и является ключевым. Сегментная 32-битная модель памяти, присутстующая у всех x86, начиная аж c 80386, молча и перманентно игнорируется всеми ОСами, каковые мне известны. Так что отобрать у любимого дитяти конфету будет-таки попроще, однако у меня даже на это рука не поднимется. Ты же предлагаешь (прости, если нет) всем программерам отказаться от любимой плоскости в пользу доброй старой сегментной модели ака Win16. Да тебя просто затопчут. А потом пойдут покупать 64-битки.
Я отнюдь не умаляю преимущества сегментных моделей, сам частенько отлаживался путём перекомпиляции в Borland С++ 4.5 + PowerPack for DOS под DPMI16, чтобы поотлавливать глюки с указателями. Или Watcom-ом под 32-бит ларж модель, но это реже. Вот только реализовать поддержку 32-битной сегментной модели памяти в ОС - это ещё тот геморрой, который ну никак дешевле 64-битных решенией не будет, не говоря уже о воплях программеров, потерявших свой любимый flat. Ты хоть можешь себе представить подкачку 4-гиговых адресных пространств? ИМХО лучшее, что можно сделать, так это ограничиться 36-разрядным физическим адресным пространством, а это, во-первых, далеко не 64ТБ, во-вторых, будет временным решением, причём очень временным. Ибо уже сейчас имеются серваки с железом, превышающим эти пределы.

Цитата AndNot @ 26.01.08, 15:46

Так какой же смысл ставить 64-х разрядную систему?

ладно, 64-х битный режим (либо х64 система) - это зло! Но всё равно скоро будут программы которым будет мало 2 ГБ (3 ГБ) вирутальной памяти, и как тогда поступить, что делать?

Сообщение отредактировано: Ahilles - 27.01.08, 16:51

Цитата Qraizer @ 27.01.08, 14:57

Ты же предлагаешь (прости, если нет) всем программерам отказаться от любимой плоскости в пользу доброй старой сегментной модели ака Win16

Да нет, ничто не стоит на месте, я вовсе не предлагаю возвращаться к старому, просто упомянул, что проблема 4Гб решается легко и непринужденно, даже без изменений архитектуры железа и незначительными изменениями менеджера памяти винды. Просто я считаю, что пока еще нет никакой необходимости переходить на 64 бит. Тот софт, что я юзаю, вполне хорошо обходится парой-другой мегабайт памяти. К примеру, на днях ставил новую систему. Встал выбор просмотровщика граф. файлов, естественно остановился на привычном ACD See, но просмотрев версии 5.хх и выше, я плюнул и установил старенькую 2.41, поскольку мне нафих не нужны все ихние навороты, мне нужен только просмотровщик, а базу я как нибудь сам организую, так же как и конвертер, так же как и поисковик и прочие фичи. Так же и с другим софтом. Это я к тому, что проблема нехватки памяти исходит от кодописателей, которые меры не знают, стараясь запихнуть в свои проги как можно больше функций, не задумываясь о том, что они там нафих не нужны, а так же забывая о приемах модульного программирования. Вот и получается, что большинство функций дублируются различными прогами, что не есть гуд. И если с умом выбирать софт, то вполне можно обойтись компом с 256 мегами памяти, как у меня, до недавнего времени. Так что рановато кричать о тех проблемах, которых просто не существует, которые просто надуманы маркетологами и глупыми юзерами(которые хватают все что блестит) Еще пример, я ни в жизь не воспользуюсь калькулятором Смайка, хотя он довольно неплох, а все потому, что есть более удачные, которые и ресурсов в десятки раз меньше жрут и функций имеют побольше, существенно уступая только по внешнему виду, - да плевать мне на обертку, я не сорока, проги по другим критериям оцениваю.

Цитата Qraizer @ 27.01.08, 14:57

Вот только реализовать поддержку 32-битной сегментной модели памяти в ОС - это ещё тот геморрой

А в чем сложность то? И так у каждой задачи своя таблица LDT, так не все ли равно, сколько селекторов будет в ней храниться? В конце-концов, зачатки подобной модели присутствуют - каждой задаче доступно до 2-х Гб виртуальной памяти, что достигается "игрой" селекторами.

Цитата Qraizer @ 27.01.08, 14:57

не говоря уже о воплях программеров, потерявших свой любимый flat

Те, кто пишет на ЯВУ, даже не заметят ничего, поскольку ограничение будет лишь на предел непрерывного участка памяти. Но часто ли программе нужен сплошной массив более 4Гб? Совсем нет. Листая инет, наткнулся на любопытный факт. Оказывается, с 2001 года игры крайне вяло наращивают требования к памяти, остановившись(большинство) на 1Гб! А ведь до этого они с каждым годом "наращивали обороты" так, что апгрейдиться не успевали Чем не показатель?

Цитата Qraizer @ 27.01.08, 14:57

Ибо уже сейчас имеются серваки с железом, превышающим эти пределы.

Не надо грести все под одну гребенку Они используют память кусками, причем не очень большими. И в таких случаях, нет абсолютно никакой разницы, что прога использует хэндл, а что селектор, для ЯВУ-программеров это будет прозрачно.

Цитата Qraizer @ 27.01.08, 14:57

Ты хоть можешь себе представить подкачку 4-гиговых адресных пространств?

Эээ, не понял, это про что?
Вообще, порывшись в инете, понял, что даже для ЯВУ-программеров переход не проходит безболезненно, далеко не всякую прогу можно, без капитальных переделок, скомпилировать под 64-х битную ОС, чего уж говорить о ассемблерщиках Нужно изучать, до тонкостей, практически новый язык, новые приемы и трюки И, кстати, что то доки пока не видно, я имею в виду толковой, а не просто тех. документацию.

Добавлено 27.01.08, 18:07

Цитата Ahilles @ 27.01.08, 16:49

Но всё равно скоро будут программы которым будет мало 2 ГБ (3 ГБ) вирутальной памяти, и как тогда поступить, что делать?

Писать свои

Цитата AndNot @ 27.01.08, 18:06

Да нет, ничто не стоит на месте, я вовсе не предлагаю возвращаться к старому

Ну, это немного другая тема. И спорить я с нею не буду. Я и сам скорее консерватор, бритвой Оккама пользоваться умею.

Цитата AndNot @ 27.01.08, 18:06

И так у каждой задачи своя таблица LDT, так не все ли равно, сколько селекторов будет в ней храниться

Всё равно. Но дело же не в количестве селекторов. Плоский указатель, читай "segment offset", по-любому больше 4Гб не охватит. Поэтому ВМ придётся реализовывать только сегментной подкачкой. Отсюда и 4 Гбайтные свопы. Проблема несколько сглаживается 36-битным адресным пространством, но её хватит только на 16 таких сегментов, и то при условии наличия столькой памяти. По три на задачу - получим с пяточек апликух, полностью высосавших весь запас. Дальше свопы, а ведь ещё самой ОС что-то надо. Не, 32-битные сегментные модели - это не для начала 21-го века. И не забудь апдейт самой ОС для поддержки этого. Не окупится, точно тебе говорю.

Цитата AndNot @ 27.01.08, 18:06

Те, кто пишет на ЯВУ, даже не заметят ничего, поскольку ограничение будет лишь на предел непрерывного участка памяти...

Да ладно. В ДОС тебе часто были нужны массивы, бОльшие 64Кб? Мне нет. Тем не менее без сегментации было никак. Что делать, такая архитектура DOS-платформы. Конечно, можно подредактировать принципы, но о затратах на проектирование и реализацию я уже высказывался.

Цитата AndNot @ 27.01.08, 18:06

Они используют память кусками, причем не очень большими...

И тем не менее, общий требуемый объём памяти огромный. Какая нафиг с него будет польза, если он будет свопиться?

Цитата AndNot @ 27.01.08, 18:06

далеко не всякую прогу можно, без капитальных переделок, скомпилировать под 64-х битную ОС

А это уже проблемы писателей. Сами виноваты. Нефиг было забивать на size_t, ptrdiff_t, std::streampos и юзать всякие там long, unsigned, а то и просто int. Так же, как пришлось бы привыкать к _far.
В общем, если резюмировать, то 64-бита простому юзеру нужны редко. И вообще вопрос, нужны ли. Но если сравнивать 32-битные сегментные и 64-битные плоские архитектуры, то последние явно в выигрыше. IBM вот в своё время тоже сделала ставку на 16-битность, не без помощи Microsoft. И как выяснилось, это было правильное решение. Хоть 16-битность и казалась поначалу окупаемой в черезчур уж далёкой перспективе. Лучше раньше начать, чем потом в спешке переделываться.