The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Intel развивает упрощённую архитектуру x86S, работающую только в 64-разрядном режиме, opennews (?), 20-Май-23, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


6. "Intel развивает упрощённую архитектуру x86S, работающую толь..."  +5 +/
Сообщение от Аноним (6), 20-Май-23, 21:18 
> 16-битные нет

Они и сейчас не работают если взять какую-то семёрку или десятку.

Ответить | Правка | Наверх | Cообщить модератору

8. "Intel развивает упрощённую архитектуру x86S, работающую толь..."  +/
Сообщение от kusb (?), 20-Май-23, 21:19 
32 разрядную?
Ответить | Правка | Наверх | Cообщить модератору

16. "Intel развивает упрощённую архитектуру x86S, работающую толь..."  +3 +/
Сообщение от Аноним (16), 20-Май-23, 21:29 
> 32 разрядную?

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

Ответить | Правка | Наверх | Cообщить модератору

60. "Intel развивает упрощённую архитектуру x86S, работающую толь..."  +/
Сообщение от Аноним (60), 20-Май-23, 22:45 
> Хотя даже ХПшку я использовал 64 разрядную, как только появился в наличии 4 пень

С ОЗУ в те времена было вроде не очень. 4 гига - предел мечтаний. Хотя могу и ошибаться.

Ответить | Правка | Наверх | Cообщить модератору

68. "Intel развивает упрощённую архитектуру x86S, работающую толь..."  +3 +/
Сообщение от Аноним (68), 20-Май-23, 22:55 
> 4 гига - предел мечтаний.

Я со вторым пнём и 512MB спокойно жил и не знал трудностей где-то до 2011 года, пока сайты вдруг не начали тяжелеть в геометрической прогрессии. 4 пень для меня, школьника а затем нищего студента, был пределом мечтаний, не говоря уж о "запредельном объёме" памяти более 1 гига))

Ответить | Правка | Наверх | Cообщить модератору

76. "Intel развивает упрощённую архитектуру x86S, работающую толь..."  +/
Сообщение от Аноним (60), 20-Май-23, 23:10 
Этот новый проц вновь поставит вопрос "память или такты" Под булеву переменную 64 бита даешь! )
Ответить | Правка | Наверх | Cообщить модератору

417. "Intel развивает упрощённую архитектуру x86S, работающую толь..."  +/
Сообщение от Аноним (-), 24-Май-23, 20:24 
> Этот новый проц вновь поставит вопрос "память или такты" Под булеву переменную
> 64 бита даешь! )

Да он и 32 не сильно хуже будет. А так - да, вы знаете, адресовать "нативный" юнит памяти сильно быстрее чем выколупывать фрагмент из него, делая RMW. И условные операции могут быть быстрее. Ну там флагами проца допустим. Скажем not zero -> jump (1 условная инструкция в многих наборах команд). А теперь представь что вместо этого надо 15-й бит в 32-битном слове проверить, потому что булеан упаковали вот туда... это уже сколько команд проца будет?! Так что да, есть speed vs RAM tradeoff.

Ответить | Правка | Наверх | Cообщить модератору

427. "Intel развивает упрощённую архитектуру x86S, работающую толь..."  +/
Сообщение от n00by (ok), 25-Май-23, 07:18 
> вы знаете, адресовать "нативный" юнит памяти сильно быстрее чем выколупывать фрагмент
> из него, делая RMW.

А на практике я взял двусвязный список, заменил указатели (64 разряда) на индексы (32 разряда). Это добавило лишнюю операцию при расчёте адреса. И дало выигрыш по скорости в 30% при работе с памятью в интерпретаторе, где такой список используется для хранения данных.

Ответить | Правка | Наверх | Cообщить модератору

435. "Intel развивает упрощённую архитектуру x86S, работающую толь..."  +/
Сообщение от Аноним (-), 25-Май-23, 20:45 
На самом деле на большом OoO проце с кешом, да еще с современным компилером где у оптимизатора свои идеи как он вооон то сделать хотел, все бывает довольно неоднозначно. Скажем эеономить RAM при гигазах вроде бы глупо. Но иногда можно получить прибавку перфоманса "потому что уместилось в кеш". Даже если вычислений и больше, из кеша они могут отработать быстрее. Более того, иногда -O3 с его unroll может все испортить, навернув более жирный код который перестал лезть в кеш или прогрузил собой шины.

А конкретно в случае процов vs булеаны у некоторых бывают инструкции для работы с битами и битовыми полями. И вот так можно конкретные биты трогать/чекать и 1 командой. Что самое ироничное, в микроконтроллернах ARM их почему-то нет :)

Ответить | Правка | Наверх | Cообщить модератору

442. "Intel развивает упрощённую архитектуру x86S, работающую толь..."  +/
Сообщение от Совершенно другой аноним (?), 26-Май-23, 10:42 
> А теперь представь что вместо этого надо 15-й бит в 32-битном слове проверить,
> потому что булеан упаковали вот туда... это уже сколько команд проца будет?!

на самом деле в даже в классической x86 архитектуре будет примерно одинаково.

в первом случае, если булевская переменная отдельно хранится, будет что-то типа:

cmp some_dword_bool, 1
jne not_one

во втором случае, если булевская переменная где-то там упакована, будет:

test some_bit_in_dword, 8000h
jz not_one

Ответить | Правка | К родителю #417 | Наверх | Cообщить модератору

446. "Intel развивает упрощённую архитектуру x86S, работающую толь..."  +/
Сообщение от n00by (ok), 26-Май-23, 13:51 
Только в первом варианте сравнение с 0м должно быть (0 или не 0).

Второй вариант потенциально быстрее: если флаги упакованы, значит они нужны примерно в одно время; при доступе ко второму он уже в кеше.

Ответить | Правка | Наверх | Cообщить модератору

447. "Intel развивает упрощённую архитектуру x86S, работающую толь..."  +/
Сообщение от Совершенно другой аноним (?), 26-Май-23, 16:32 
> Только в первом варианте сравнение с 0м должно быть (0 или не 0).

можно и так, всё-таки true, по-логике, тоже имеет только одно значение.

> Второй вариант потенциально быстрее: если флаги упакованы, значит они нужны примерно в
> одно время; при доступе ко второму он уже в кеше.

там ещё надо потактовки смотреть, а лучше - во что это всё выльется для каждой из архитектур, с учётом uops и задействованных внутренних блоков. А то, например, сделали такую замечательную команду BEXTR, которая может битовое поле вытащить без сдвигов и масок, вот только оказалось, что быстрее она будет работать только на процессорах AMD, на Intel никакой пользы от неё нет[1].

[1] https://reviews.llvm.org/D52570

Ответить | Правка | Наверх | Cообщить модератору

449. "Intel развивает упрощённую архитектуру x86S, работающую толь..."  +/
Сообщение от n00by (ok), 27-Май-23, 07:07 
А на чём смотреть потактовки? Раньше была утилита AMD CodeAnalyst - вот она после прогонки выполняла симуляцию конвейера и строила график, где каждая команда разбивалась на микрооперации. Рядом с прямоугольниками параллельно исполняющихся инструкций, где при замене инструкций разброс был в пару тактов, промахи кеша в сотню тактов выглядели очень печально. В uProf этого нет, а у intel никогда и не было (разработчик vTune объяснил мне в своё время, что это вообще не нужно).
Ответить | Правка | Наверх | Cообщить модератору

451. "Intel развивает упрощённую архитектуру x86S, работающую толь..."  +/
Сообщение от Совершенно другой аноним (?), 27-Май-23, 10:09 
> А на чём смотреть потактовки?

как я понял, разработчики компиляторов пользуются табличками https://uops.info/table.html и сервисом godbolt.org (https://godbolt.org/z/zdktz_)

Ответить | Правка | К родителю #449 | Наверх | Cообщить модератору

452. "Intel развивает упрощённую архитектуру x86S, работающую толь..."  +/
Сообщение от n00by (ok), 27-Май-23, 10:41 
Ну, скажем, для ADC (R64, M64) указана латентность 1 и пропускная способность 2. Значит и для TEST столько же или лучше. В теории, процессор может выполнить две такие команды за такт. А на практике окажется промах кеша, процессор примется ждать, пока данные считаются из ОЗУ, и вообще переключится на второй поток HyperThreading. Потому чем компактнее данные расположены в памяти, тем они вероятнее окажутся в кеше, что потенциально лучше для скорости.
Ответить | Правка | К родителю #451 | Наверх | Cообщить модератору

456. "Intel развивает упрощённую архитектуру x86S, работающую толь..."  +/
Сообщение от Совершенно другой аноним (?), 27-Май-23, 12:11 
> Ну, скажем, для ADC (R64, M64) указана латентность 1 и пропускная способность
> 2. Значит и для TEST столько же или лучше. В теории,
> процессор может выполнить две такие команды за такт. А на практике
> окажется промах кеша, процессор примется ждать, пока данные считаются из ОЗУ,
> и вообще переключится на второй поток HyperThreading. Потому чем компактнее данные
> расположены в памяти, тем они вероятнее окажутся в кеше, что потенциально
> лучше для скорости.

Вы можете сами провести эксперименты. В частности для исходных cmp vs test, при прочих равных, разницы не будет: https://godbolt.org/z/8Kc371aMK

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

Ответить | Правка | К родителю #452 | Наверх | Cообщить модератору

463. "Intel развивает упрощённую архитектуру x86S, работающую толь..."  +/
Сообщение от n00by (ok), 27-Май-23, 14:52 
К сожалению, сейчас поисковики по запросу AMD CodeAnalyst pipeline simulation не выдали мне подходящих картинок, что бы можно было наглядно показать, о чём я говорю.

Что CMP и TEST исполняются одинаково, как и большинство арифметико-логических команд (за исключением ADC/SBC) - это мне известно из IA Software Optimization Manual. Ключевой момент - "при прочих равных". Когда две такие команды стоят подряд и обращаются к одной ячейке (проверяют разные биты) - это один вариант. Когда они обращаются к разным - это другой вариант, здесь на второй команде потенциально будет загрузка линейки кеша из ОЗУ. godbolt тут не поможет. Что-то можно сделать утилитой perf, но локализовать проблемное место приходится методом тыка.

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

Это верно, я не рассматривал такой вариант, поскольку это надо специально умудрится так написать.

Ответить | Правка | К родителю #456 | Наверх | Cообщить модератору

491. "Intel развивает упрощённую архитектуру x86S, работающую толь..."  +/
Сообщение от Аноним (-), 29-Май-23, 01:21 
> Только в первом варианте сравнение с 0м должно быть (0 или не 0).

Кроме сравнений...
1) Флаг еще надо и выставить/очистить. Черт знает как в x86 а в ARM-подобных условный MOV r0, #1 будет коротко и эффективно. Это лобовая, немедленная операция, в тот же такт. А чтобы вот именно в 15 бите поменять надо RMW, явно не 1 immediate операция.
2) Это еще и взаимодействует с оптимизером и соседними сегментами кода. Скажем оптимизер типа LTO может реюзануть вгрузку тех или иных констант для чего-то совсем побочного и неслабо оптимизнуть посторонний код. С простыми константами в регистр это работает лучше чем сложным битовым словом. Если компилер точно знает что в r0 сейчас 1, он может использовать r0 для каких-то побочных вычислений где надо было константу 1 - полностью удалив загрузку регистра вот там, для их нужд. Если бы этого не было - он бы конечно честно оформил, но раз оно есть, то может быть реюзнуто. В этом весь смысл глобальной оптимизации типа LTO и состоит.

Ответить | Правка | К родителю #446 | Наверх | Cообщить модератору

86. "Intel развивает упрощённую архитектуру x86S, работающую толь..."  –1 +/
Сообщение от Ivan_83 (ok), 20-Май-23, 23:54 
Мне в 2007 году перестало хватать п3-1100@1466 с 512 оперативы.
Началось с моника на 23 - пришлось видяху новую ставить, и мышку, а потом я скачал рип 720р и не смог посмотреть - это был приговор.
Ответить | Правка | К родителю #68 | Наверх | Cообщить модератору

87. "Intel развивает упрощённую архитектуру x86S, работающую толь..."  +/
Сообщение от Аноним (87), 21-Май-23, 00:03 
> Мне в 2007 году перестало хватать п3-1100@1466 с 512 оперативы.

Чем вы таким занимались что этого перестало хватать? На этой конфигурации и сейчас можно не просто выживать, а ещё и работать, если поставить какой-нибудь антикс линукс.

> рип 720р и не смог посмотреть

Похоже вы батенька фантазёр, 720p даже на первых пнях БЕЗ mmx играло, если видюха умела в аппаратный декодинг (а они почти все умели).

Ответить | Правка | Наверх | Cообщить модератору

92. "Intel развивает упрощённую архитектуру x86S, работающую толь..."  –1 +/
Сообщение от Ivan_83 (ok), 21-Май-23, 00:19 
Компеляторв вижалстудии долго собирал, и кино в 720р не крутило.

Поди найди видяху с AGP и аппаратным h.264, или ты DivX аппаратный где то видел?)

Ответить | Правка | Наверх | Cообщить модератору

217. "Intel развивает упрощённую архитектуру x86S, работающую толь..."  –2 +/
Сообщение от FF (?), 21-Май-23, 17:06 
какие 720p? 720x576 может быть?
Ответить | Правка | К родителю #87 | Наверх | Cообщить модератору

310. "Intel развивает упрощённую архитектуру x86S, работающую толь..."  +/
Сообщение от Аноним (310), 22-Май-23, 12:10 
Видеокарты тогда хорошо если 24-битный цвет умели. Matrox Millenium был пределом мечтаний, а стандартом S3 Trio 64 V+.
DivX нормального разрешения тянул уже не любой Pentium-II.
Ответить | Правка | К родителю #87 | Наверх | Cообщить модератору

382. "Intel развивает упрощённую архитектуру x86S, работающую толь..."  +/
Сообщение от 1 (??), 23-Май-23, 10:04 
да, ладно))) в 2007 S3 Trio 64 V+ ? Вот в 1997 это еще было.
Ответить | Правка | Наверх | Cообщить модератору

418. "Intel развивает упрощённую архитектуру x86S, работающую толь..."  +/
Сообщение от Аноним (-), 24-Май-23, 20:36 
> Чем вы таким занимались что этого перестало хватать?

Ну, э, допустим в каде порисовать. Или скомпилять более-менее жирный проект размером с линукскернел.

Скомпилять его на п3 с 512 оперативы, конечно, можно. В 1 малохольный поток. А теперь пустим сборку на вооон том 16-ядернике с 32 гиг оперативки, подохренеем с разницы во времени этой операции. И подумаем - может, если этим заниматься всерьез, раз в жизни себе нормальный комп купить все же? Из соображений разгона эффетивности.

Или вот равка с камеры. Немного ее покрутить... эээ... она в байере более 20 мегов весит. А в RGB и того больше. А еще самой программе места в памяти надо. Undo всякое и кеши предппросмотра... без этого всего конечно можно, но работать будет как фотошоп на 95 винде с 16 мегами памяти, по тем же причинам. А на компе с 16 мегами памяти вы бы 20-метровую равку вообще обрабатывать не стали бы, из-за нереалистичного времени на свопление этого счастья.

> сейчас можно не просто выживать, а ещё и работать, если поставить
> какой-нибудь антикс линукс.

Работать... ну смотря кем, конечно. Если просто ломовым сишным кодером, только мелкие проектики - еще можно попытаться. И даже так какой-нибудь плеер в фоне сборку тормознет ощутимо. Блин, у меня телефон мощнее чем это, может тогда лучше на телефоне билдовать?! Он и энергии в 100 раз меньше жрет.

> Похоже вы батенька фантазёр, 720p даже на первых пнях БЕЗ mmx играло,
> если видюха умела в аппаратный декодинг (а они почти все умели).

Во первых, большая часть видях как раз никакого декодинга не умели. И форматов тогла были только мпег 1 и 2 которым чтобы не выглядеть как УГ надо ломовой битрейт. И справлялись с этим только отдельные хардварные карты акселераторов, которые мало у кого были. Потому что отдельная карта, за отдельную цену. Потом компы стали мощнее и всякие ранние Mpeg4 появились типа DivX ;) (смайлик в оном прозрачно намекает что это перепертый MS MPEG4v3). Ну а потом уже всякие xvid начались и проч, с довольно крутыми оптимизациями, и там уже третьепень имел некие шансы на не сильно жирном потоке. Что-то такое спраяляется с небольшими потоками XVID и VP8. H.264 даже самый ерундовый уже не потянет, так что даже торенты не посмотришь, разве что совсем олдовые.

Ответить | Правка | К родителю #87 | Наверх | Cообщить модератору

85. "Intel развивает упрощённую архитектуру x86S, работающую толь..."  +7 +/
Сообщение от Ivan_83 (ok), 20-Май-23, 23:48 
ХР появилась в 2002 году вроде или 2003 весной.
Тогда было много п3 с 64-256 мб озу, но были и П4 уже.
Вылизанная ХР32 потребляла после загрузки 96-128мб озу, и на 256мб+ ей жилось неплохо.
В п3 вставало до 512/768мб в зависимости от чипсета.

4+ гига это более менее массово началось после коредуо, те 2008+ год, до того у совсем энтузиастов, хотя всякие жмоты и в 2015 году жили на 1-2 гб оперативы.

Ставить ХР64 - большая глупость, когда можно было поставить 2к3х64 и не иметь никаких проблем вообще, да ещё и поддержку GPT получить и всякие зеркала софтварные.

Ответить | Правка | К родителю #60 | Наверх | Cообщить модератору

89. "Intel развивает упрощённую архитектуру x86S, работающую толь..."  –1 +/
Сообщение от Аноним (87), 21-Май-23, 00:05 
> поддержку GPT получить

Нафуя? Тогда диски были 20-40 гигов в среднем. И поголовно в fat32 чтобы ресурсы не тратить на ntfs потому что ntfs нафиг не нужна на домашнем компе. Я даже сейчас не знаю зачем нужно GPT если это не сервер.

Ответить | Правка | Наверх | Cообщить модератору

94. "Intel развивает упрощённую архитектуру x86S, работающую толь..."  –1 +/
Сообщение от Ivan_83 (ok), 21-Май-23, 00:22 
Использовать FAT32 на ХР - огромная глупость.
40гб диски были в 2003-5 годах, к 2007-8 они уже переросли MBR.
GPT нынче везде, кроме странных лудитов, и она банально удобнее и понятнее чем мбр.
Ответить | Правка | Наверх | Cообщить модератору

102. "Intel развивает упрощённую архитектуру x86S, работающую толь..."  +/
Сообщение от Аноним (102), 21-Май-23, 00:54 
> огромная глупость

Писать подобные комменты будучи на айтишном сайте.

> лудитов

Ты ошибся сайтом, тебе к клоунам и петросянам.

Ответить | Правка | Наверх | Cообщить модератору

108. "Intel развивает упрощённую архитектуру x86S, работающую толь..."  –2 +/
Сообщение от Ivan_83 (ok), 21-Май-23, 01:08 
На FAT32 сидели дурачки, которые сидели под админом и им было пофик что можно случайно снести систему неловким движением мышки в проводнике.
Про всякие вирусы я молчу.

Активно пересаживал всех клиентов на ХР под обычного юзера, естессно на NTFS и оно работало у людей годами, и даже без всяких антивирусов с небольшим подтягиванием гаек в реестре (локальная политика безопасности) никакой гадости не разводилось.

Не знаю что вы там на своём FAT32 наэкономили, когда я отключал всё ненужное и получал после бута 128мб оперативы занятой системой.

И отдельно отмечу что NTFS был просто шикарен после FAT32 которому после каждого хард ребута нужна была проверка, можно сказать что он был неубиваемым из коробки.

Ответить | Правка | Наверх | Cообщить модератору

209. "Intel развивает упрощённую архитектуру x86S, работающую толь..."  –1 +/
Сообщение от Аноним (209), 21-Май-23, 16:12 
В XP пользователь обычно был админом, вирус цеплял после необдуманого клика баннера. А если не админом - половина программ не работали. И уж 5 тулбаров в браузере обычное дело. Линуксы в руках профанов устойчивее, там случайно поставить софт сложно.
Ответить | Правка | Наверх | Cообщить модератору

307. "Intel развивает упрощённую архитектуру x86S, работающую толь..."  +/
Сообщение от RANDOMIZE USR 15616 (?), 22-Май-23, 11:10 
>> без всяких антивирусов с небольшим подтягиванием гаек в реестре (локальная политика безопасности) никакой гадости не разводилось.

А потом вирусня начала ставиться в Local Settings (включаяя всякие Амиго-браузеры) и вся эта политика безопасности пошла по женской линии.

Ответить | Правка | К родителю #108 | Наверх | Cообщить модератору

163. "Intel развивает упрощённую архитектуру x86S, работающую толь..."  +/
Сообщение от Аноним (163), 21-Май-23, 11:18 
Для большинства пользлвателей что GPT что MBR монопенисуально потому что у большинства два раздела и дисков тоже штуки две максимум.
Ответить | Правка | К родителю #94 | Наверх | Cообщить модератору

318. "Intel развивает упрощённую архитектуру x86S, работающую толь..."  +/
Сообщение от Аноним (318), 22-Май-23, 12:53 
> Для большинства пользлвателей что GPT что MBR монопенисуально потому что у большинства
> два раздела и дисков тоже штуки две максимум.

У MBR 2 ТБ ограничение, ты тут втираешь какую-то дичь. И как это большинство пользователей столкнётся с этой дос-разсеткой, если венда её давно закопала? Кстати насчёт двух разделов, у _большинства_ таки в районе десятка разделов, поскольку это стандартная тема. Тебе часто говорят, что ты некомпетентный, и тебе стоит воздержатся от ответов в интернете в принципе?

Ответить | Правка | Наверх | Cообщить модератору

105. "Intel развивает упрощённую архитектуру x86S, работающую толь..."  +/
Сообщение от Аноним (105), 21-Май-23, 00:58 
Для дисков больше 2TB, для легаси MBR это максимальный лимит.
А дисков сейчас много и до 20TB.
Ответить | Правка | К родителю #89 | Наверх | Cообщить модератору

257. "Intel развивает упрощённую архитектуру x86S, работающую толь..."  +/
Сообщение от Аноним (257), 21-Май-23, 22:16 
> Ставить ХР64 - большая глупость, когда можно было поставить 2к3х64 и не
> иметь никаких проблем вообще, да ещё и поддержку GPT получить и
> всякие зеркала софтварные.

XP64 - это просто клиентская версия 2003 X64.
Так что работали бы они одинаково.

Ответить | Правка | К родителю #85 | Наверх | Cообщить модератору

284. "Intel развивает упрощённую архитектуру x86S, работающую толь..."  +/
Сообщение от ryoken (ok), 22-Май-23, 07:43 
>>В п3 вставало до 512/768мб в зависимости от чипсета.

Мой домашний CUBX-E с P3-750 и 1Гб RAM смотрит на это с ухмылкой :). Ну и под 98-й вантуз добрый человек сделал патчи для работы с такими объёмами, а его родственники выдали в бесплатный доступ их.

Ответить | Правка | К родителю #85 | Наверх | Cообщить модератору

218. "Intel развивает упрощённую архитектуру x86S, работающую толь..."  +4 +/
Сообщение от FF (?), 21-Май-23, 17:08 
64-битная ОС нужна не для доступа за пределы 4ГБ. Там в 2 раза больше регистров проца. Но из-за того, что адреса памяти стали в 2 раза длинее, потребление ОЗУ у дистрибутивов в среднем поднялось на 30%, а у хромобраузера -- на 50%.
Ответить | Правка | К родителю #60 | Наверх | Cообщить модератору

236. "Intel развивает упрощённую архитектуру x86S, работающую толь..."  +/
Сообщение от Аноним (236), 21-Май-23, 19:40 
Если сейчас недопека(планшетное железо, или просто "старый пень"), которые хоть и умеют в 64 бита, но памяти имеют 4- гига, то даже win10 32 бита, т.к. значительно меньше жрётся памяти, и хватает даже браузеру на сильно больше страниц.
Ответить | Правка | К родителю #60 | Наверх | Cообщить модератору

311. "Intel развивает упрощённую архитектуру x86S, работающую толь..."  +/
Сообщение от Аноним (310), 22-Май-23, 12:14 
Только 4 гига-то вы не получите на 32 битах. Так что в производительности вы проиграете, а по памяти хорошо если в ноль выйдете.
Ответить | Правка | Наверх | Cообщить модератору

321. "Intel развивает упрощённую архитектуру x86S, работающую толь..."  +/
Сообщение от _kp (ok), 22-Май-23, 12:58 
> Только 4 гига-то вы не получите на 32 битах. Так что в
> производительности вы проиграете, а по памяти хорошо если в ноль выйдете.

Бывают исключения.
В "золотой век" планшетов на одноядерном Атоме, с 2ГБ ОЗУ использовал Win7 64bit.
Для игр, которые к тому же 32х битные были тогда, это давало и строго проигрыш, и жор ОЗУ, и многое не вообще запускалось. Браузеру тоже это на пользу не шло.
А для программирования, 64 битная семерка работала быстрее.
Разница в быстродействии стоила двойной загрузки.

Ответить | Правка | Наверх | Cообщить модератору

360. "Intel развивает упрощённую архитектуру x86S, работающую толь..."  +/
Сообщение от MaleDog (?), 22-Май-23, 23:25 
Там была такая проблема. 32 разрядное приложение в windows не могло адресовать более 2 Гб оперативной памяти, тогда в винде это считалось неким дополнительным фактором стабильности, ведь если вы не можете адресовать память выше 4 гигов и часть еще съели биос и встроенная видеокарта, то это угроза стабильности системы. А еще 32-битные приложения тогда занимали ощутимо меньше оперативной памяти, если не в 2 то уж в полтора раза точно. Но уже в XP был ключик для запуска ядра со снятием лимита в 2 Гб, но как говорится, на свой страх и риск, как отключение свопа. Этим пользовались 1С-ники в основном и позже игроманы, которые не хотели слезать с XP. Это было искусственное ограничение, так как со времен итаниума существовало PAE. Причем в 32 разрядных windows оно присутствовало в  enterprise версиях (а значит за легальное использование простили деньги, а в linux/freebsd даром). PAE позволяло адресовать 32-битной системе до 32 гигабайт памяти. А это и сейчас для среднего пользователя идеал. Словом можно и в настоящее время жить на 32-битной системе. Есть 32-разрядные версии windows 10. Но вот половину приложений уже давно перестали собирать с поддержкой 32-разрядного режима.
Ответить | Правка | К родителю #60 | Наверх | Cообщить модератору

363. "Intel развивает упрощённую архитектуру x86S, работающую толь..."  +/
Сообщение от Аноним (363), 23-Май-23, 00:17 
>[оверквотинг удален]
> со снятием лимита в 2 Гб, но как говорится, на свой
> страх и риск, как отключение свопа. Этим пользовались 1С-ники в основном
> и позже игроманы, которые не хотели слезать с XP. Это было
> искусственное ограничение, так как со времен итаниума существовало PAE. Причем в
> 32 разрядных windows оно присутствовало в  enterprise версиях (а значит
> за легальное использование простили деньги, а в linux/freebsd даром). PAE позволяло
> адресовать 32-битной системе до 32 гигабайт памяти. А это и сейчас
> для среднего пользователя идеал. Словом можно и в настоящее время жить
> на 32-битной системе. Есть 32-разрядные версии windows 10. Но вот половину
> приложений уже давно перестали собирать с поддержкой 32-разрядного режима.

1. PAE was first implemented in the Intel Pentium Pro in 1995
2. винда, 1с-ники, промышленный софт :).

Ответить | Правка | Наверх | Cообщить модератору

482. "Intel развивает упрощённую архитектуру x86S, работающую толь..."  +/
Сообщение от Аноним (-), 28-Май-23, 19:02 
Наверняка дело в том, что где-то один раз использовали 32 битное со знаком, а потом просто для совместимости оставляли по умолчанию предполагая худший вариант
Ответить | Правка | К родителю #360 | Наверх | Cообщить модератору

162. "Intel развивает упрощённую архитектуру x86S, работающую толь..."  –2 +/
Сообщение от Аноним (163), 21-Май-23, 11:12 
А смысл если большинство прогрпмм 32 разрядные?
Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

293. "Intel развивает упрощённую архитектуру x86S, работающую толь..."  +1 +/
Сообщение от Аноним (363), 22-Май-23, 09:39 
Какое нафик большинство? Ненужный шлак.
Ответить | Правка | Наверх | Cообщить модератору

93. "Intel развивает упрощённую архитектуру x86S, работающую толь..."  +/
Сообщение от X512 (?), 21-Май-23, 00:21 
Работают через сторонний софт WineVDM (https://github.com/otya128/winevdm).
Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

136. "Intel развивает упрощённую архитектуру x86S, работающую толь..."  +/
Сообщение от Аноним (136), 21-Май-23, 09:21 
В 32-х битных Windows 7 и Windows 10 работают
Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру