» Windows 98 SE (оптимизация и улучшение) — восьмая часть

Цитата:

А что такое SATA-патч и где его можно раздобыть?

сначала попробуй без него. просто в биосе IDE выстави вместо AHCI. может, и не понадобится патч.

MERCURY127

Цитата:

вообще то, как раз 16-битный код из 64-битного никак не запустить без потерь. в х64 режиме нет префиксов для 16-битных операндов,

Перенести нужный софт на Unix/Linux и не париться с этим динозавровым DOS. Заодно и памяти будет вдоволь и все полезные фишки современных CPU. В несколько десятков раз можно производительность поднять, по сравнению с DOS.


Цитата:

грубо говоря, начиная с 7 или ХР, не знаю точно, если работате 1 ядро, оно например у меня работате на 4300. все 4 - на 4100. но в 98 и досе - всегда 3400, хотя тк больше 1 ядра там не может быть

У меня вроде без проблем. Тут вроде не только от CPU зависит, но и от материнской платы. Недавно видел системник, проц чуть новее моего, материнка также, производитель тот же, а в BIOS там ничего на этот счёт, проц на одной частоте пашет во всех режимах.

Посмотрю у себя конкретнее, сейчас тот комп занят обработкой 70 часов видео, не быстрое это дело. Пашет всеми ядрами на максимальной разрешённой частоте.

Monohromator

Цитата:

С оборудованием, вроде, все в порядке. Видеокарта Geforce 6600,

А зачем Вам игровая видеокарта для каких-то там вычислений в DOS? Если есть PCI слот, воткнули Trident и нет проблем.

Цитата:

Перенести нужный софт на Unix/Linux

да да, попробуй, переведи ассемблерные вставки с обращением к портам и памяти...

MERCURY127

Цитата:

да да, попробуй, переведи ассемблерные вставки с обращением к портам и памяти...

Если сам автор софта, какие проблемы? Кому не лень DOS игры даже на Колибри переносят.

Monohromator

Цитата:

ссылки на скачивание новый сборок Win98IF (если они существуют)

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

Цитата:

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

Да, основная проблема именно в памяти, но бьет она не только по видеокарте - ещё по драйверу HDD, по виртуальной машине DOS... То есть шансов завести полноценный режим у вас мало, а в безопасном ещё неизвестно что будет с ДОСом.
Для чистой же ДОС этих проблем не существует. С высокой вероятностью вам придется-таки работать именно в чистой ДОС. Мне так кажется.

Цитата:

Э, господин ZSZ, а вы таки хам.

С первого же сообщения - сразу диагноз! Браво.

Цитата:

MERCURY, SimpleStas, SweetLow и прочие разработчики "пожирателей"

Боюсь, разработчиков здесь нет. Остались только коллекционеры этих продуктов.

Цитата:

желательно не усб клава/мышь. хотя с последними это наверное только мне так не повезло...

вероятно. Во всяком случае у меня с этим проблем не было.

"Если сам автор софта, какие проблемы"
Вот пишешь ты например драйвер для железки. Если делаешь это под ДОС тебе стоит парится только о своих косяках и косяках железа, а под виндой ещё и о косяках ядра ОСи.

По поводу быстродействия: никто не запрещает при запуске программы перевести проц в защищённый режим (типа игр с DOS4GW) и это однозначно быстрей в сравнении с Win98, неговоря уже о про сетевые WInNT и *Nix-ы.

"в X64 режиме"
Я как-то считал что просто добавились микрокоманды, ну и некоторые регистры стали 64битными. т. е. ну у 32битного проца есть реальный режим, вот незнаю доступны ли из него например mov eax,ebx и т. п., и защищённый, в котором вродебы недоступны тотько 16битные сегментные регистры ss, ds, es.
Ты имеешь в виду что в 64битном проце появился ещё один режим над защищённым, только из которого доступны 64битные микрокоманды? но при этом вообще не работают 16битные (типа mov al.bh)?

HNKTO, х86 и ее потомки - самая уепищная архитектура на уровне опкодов. Она родилась как 8080, потом ее тянули через 16 бит к 32 и дотянули до 64. При этом адресацию тянули от 8 бит через 16, 20, 24, 32, 36, 48 до 64. А ведь ещё есть порты в/в и прерывания...
И на каждом шаге пытались обеспечить максимальную обратную совместимость весьма оригинальными и извращеными способами. Даже там, где она нах не нужна.
Благодаря этой совместимости х86 стал монополистом. С точки зрения бизнеса это было верное решение. Но с точки зрения техники...
х86 - монстр. Гибрид танка, самосвала и шагающего экскаватора, все на цепной передаче.
Этот монстр быстрый, неприхотливый, перемалывает все. Но это все благодаря тому, что внутри него его работу делает совсем другой процессор. Не х86. Не 8/16/32/64 битный. И вообще ничего не знающий про регистры al/si/esp/rdx/gs.
Тебе будет смешно, но как раз Add al, dl в х64 режиме спокойно выполняется.
Не выполняется add bl, dh и любые 16 битные. И способ их выполненить без выхода из х64 только один - эмуляция через процедуры.

опять-же "без выхода из х64"
что ты под этим имеешь в виду? Переключение в реальный режим?
Кстати раз так, интересно возможно ли скажем на пне3 адресовать память > 1мб не переключаясь в защищённый? (как himem работает?)

"Этот монстр быстрый" o_0 неужели невыйдет сделать RISC-овый ARM который на решении конкретной задачи не уделает любые существующие x86 варианты?

"его работу делает совсем другой процессор" а можно поподробней? ты мне уже в своё время пояснял чно начиная эдак с пней2 х86 уже не CISC по внутренней сути, но я тогда так понял что современный ЦП - это микрокомпьютер на кристале с целым набором RISC процессоров, каждый под свою область.

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

Цитата:

возможно ли скажем на пне3 адресовать память > 1мб не переключаясь в защищённый? (как himem работает?)

легко делается начиная с 386. но код остается в пределах 16 бит - один сегмент в 64 кб. зато строки до 4 гб двигать - в один присест.
хаймем умеет по разному, обычно именно так и делает.

Цитата:

сделать RISC-овый ARM который на решении конкретной задачи не уделает любые существующие x86 варианты?

дык уже - это и есть современный х86. не арм, это да. но и арм можно разогнать до 4+ ггц, добить мегабайты кеша, ссе, авх - и получится 100 вт монстр с сопоставимой производительностью. быстрее не будет, будет наравне.

Цитата:

чно начиная эдак с пней2 х86 уже не CISC по внутренней сути, но я тогда так понял что современный ЦП - это микрокомпьютер на кристале с целым набором RISC процессоров, каждый под свою область.

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

Цитата:

опять-же "без выхода из х64"

позже распишу, это долго. проще загуглить amd64 long mode и посмотреть, как переиначены префиксы 66h/67h...
выход - значит именно выход в другую вирт машину, со своими АП, ПВВ, супервизором - все в режиме х32 (те эпоха до амд64), или даже в реальный режим, если гипервизор позволит (вмваря)... и все только для того, чтоб add bp, ax?

MERCURY127

Цитата:

Благодаря этой совместимости х86 стал монополистом. С точки зрения бизнеса это было верное решение.

Всё было как раз наоборот: IBM настолько считала всё это несерьёзным по своим меркам, что всю архитектуру IBM PC сделала открытой - берите, пользуйтесь этой ИГРУШКОЙ, нам не жалко! И именно поэтому IBM PC захватил весь рынок. Потому что любой китаец мог делать такие же, и никому за это не отстёгивать.
Обрадовавшись такому успеху IBM следующую крутую машину PS/2 с перспективной шиной MCA запатентовала везде где можно и уже готовилась снимать сливки... А не пошло!
Так бесплатное побеждает хорошее.

"но код остается в пределах 16 бит - один сегмент в 64 кб" тоесть поюзать в реальном режиме 32битные микрокоманды и регистры мы не можем или можем, но попытки адресовать память выше одного метра всё-равно не прокатят?
Или ты имеешь в виду логичное следствие что конкретно для 8/16 битных микрокоманд в реальном режиме > 1мб - никак (да и в защищённом в пределах 1Мб, но уже не обязательно первого).

Добавлено:
"PS/2 с перспективной шиной MCA запатентовала везде где можно"
так копирайт убивает хорошие идеи. Кстати к Win9x помоему это тоже весьма применимо.

Цитата:

доказательство - почти прямая пропорциональность между гфлопсами и ваттами

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

HNKTO

Цитата:

так копирайт убивает хорошие идеи

Жадность их убивает. Коллеги, не жадничайте!

Унификация - это хорошо. Когда она как в nec v20/v30 (прямое исполнение кода 8080), как в 386 (на редкость удачная реализация плюс прямое исполнение кода 8086). А вот х86-64 рожали две мамки сразу, получился бардак, хорошо хоть 32хбитный код напрямую без особых граблей запускается. Но вот реальный режим (16 бит) нужно было выбрасывать уже. Оставили только потому, что внутреннему РИСКу в принципе без разницы, чего перемалывать. Но вот опкодов для трехрежимного исполнения 64/32/16 уже не хватает, равно как и два 64 битных операнда в 15 байтовую команду не влезают... Итого 64 битный процессор получился немножко инвалидом...

Добавлено:

Цитата:

тоесть поюзать в реальном режиме 32битные микрокоманды и регистры мы не можем или можем, но попытки адресовать память выше одного метра всё-равно не прокатят?

с точностью до наоборот. Любые команды, любые данные, но только 64 кб кода на все. Только один сегмент cs.

"Но вот реальный режим"
ну вот 16 бит может быть, хотя старый софт и сегодня гоняют - объективно нужен) но если реальный режим как таковой то мне страшно представить необходимый для старта такой системы гемор (с точки зрения процесса запуска БИОС, да и дальнейшего переброса на ОС).

"о вот опкодов для трехрежимного исполнения" т. е. в эпоху х32 успели занять все свободные биты сетки микрокоманд мыслимых для x32?

"15 байтовую команду"
вот а что им мешало сделать комманды больше 15 байт? короче примерно понял: как и с рождением защищённого режима: родилось через жопу. И теперь будет лечится десяток лет.

"и каждый раз всё-таки придумывают, как можно ещё уменьшить размеры"
ну, исторические реалии таковы, тут я больше про мир игровых приставок, когда выходила замечательная, производительная приставка, но с кучей процессоров, сопроцессоров она оказывалась в целом провальной т. к. разработчики не хотели и не хотят возится с распараллеливанием кода. Можно запилить овер 32х ядерный пентиум3 и он будет шустрее corei7, но сколько разработчиков игр захотят эффективно нагрузить все эти 32 ядра? А куда делся MPU из современных компов? Да на музыку в играх объективно положили.

"Любые команды, любые данные, но только 64 кб кода на все"
Непонял. ... Ну а-ля mov edi,0h mov eax,edi:[008FFD40H] даст эффективный результат? (т. е. данные из памяти по адресу 0x008FFD40)(то что IP в реальном режиме должен быть по умолчанию 16битным и сответственно код окнами по 64кб в пределах первого 1мб т. к. cs 32битным не стал)

Monohromator,
+ ты ещё попробуй поставить отдельно IFko-шный ДОС, поставитиь туда выданный XMGR, а уже затем запускать установку винды, монитиоря чтоб она не ломала ДОС под ней (не совала свой himem) - на п4 на работе 98я ровно вставала именно так, причём лимитирование ОЗУ было не обязательно - только наличие.
* знаки подчёркивания вместо русских буков в безопаске - признак что винда до конца не поставилась, конкретней - нету базово необходимых шрифтов (или их загрузить не выходит).

Цитата:

Непонял. ... Ну а-ля mov edi,0h   mov eax,edi:[008FFD40H] даст эффективный результат? (т. е. данные из памяти по адресу 0x008FFD40)(то что IP в реальном режиме должен быть по умолчанию 16битным и сответственно код окнами по 64кб в пределах первого 1мб т. к. cs 32битным не стал)

не cs, а ip. Ip не станет от этого eip. Более того, к cs теперь вообще обращаться нельзя - те двинуть окно кода даже в пределах классического первого мб не выйдет - этот тн unreal mode по сути прерванный на полпути переход в зр, и обращение к cs продолжит этот переход, а тк сегмент кода/стека зр не готов - будет немедленная ошибка защиты, обработать которую в реальном режиме некому. И процессор получает double или triple fault и обрабатывает это ребутом...
А с остальными регистрами, командами, адресами, смещениями делай что хочешь... Вот только с 64 кб кода не очень то разгуляешься, тк длина команд для работы с такими 32 битными данными и адресами из 16 битного сегмента кода ровно вдвое больше обычных 16 битных родственников.

Всё-равно непонял. Ты имеешь в виду что при первой встрече mov eax,edi:[008FFD40H] и т. п. процессор БЕЗ моей конкретной указки попробует перейти в защищённый режим? или в нём всё станет наперекосяк, выраженный в невозможности скажем следующим шагом выполнить лонгджамп?
Да в принципе наверно забей. Разберусь как это всё засунуть в asm и заставить tasm v5 это всё скомпилить без ошибок и переиначиваний и сам посмотрю как оно работает.

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

ZSZ
3D Mark
PCMark

goodman4444

Цитата:

3D Mark PCMark

Не припомню версий под DOS. И по приведённым ссылкам ничего про это не говорится.

ZSZ

Цитата:

Не припомню версий под DOS

в ассортименте и ещё здесь

Цитата:

mov eax,edi:[008FFD40H]

я тебе про ds/es/fs/gs что то говорил? нет. к этим сегментам можно обращаться без проблем. про ss не уверен, но вроде push/pop/call/ret работают.
поэтому mov eax,edi:[008FFD40H] пройдет без проблем, при условии, что сегменты ds/es переведены в 32 лимит. но этого обычно не делают, тк тогда придется отслеживать действия самого ДОСа и кучи обычных 16 бит онли программ. те писать полноценный дпми хост. тогда и сразу cs виртуализировать.
поэтому берут регистры (сегменты), о которых нормальные ДОС приложения ни слухом, ни духом - FS: & GS: (они появились только в 386)
и делают как бы переход в ЗР, но в таблицу ГДТ прописывают базу 0/лимит 3FFFF только для этих (или одного из них) FS и GS, остальное не трогают. равно как не инициализируют ИДТ/ЛДТ. и дальше переход в ЗР не делают (флаг в регистре CRx не трогают).
в результате процессор остается подвешенным на полпути в ЗР:
mov eax,GS:edi:[008FFD40H]
mov FS:ebx:[008FFD40H],0abcdef00
FS:scasd
stosw (в пределах оставшегося 16 битным es
call 2345
jz 55
все работает (jnz 9999 - не уверен)

а вот
call/jmp 0a83e000
call/jmp 07262:0a83e
push 0a83e, push 07262, retf
это не должно работать.
равно как и все mov cs/ds/es/ss/fs/gs, ax

goodman4444
Там везде требуется Windows. А нужна программа для DOS.

Aleksandr SHCH

Цитата:

Там везде требуется Windows. А нужна программа для DOS.

Обычно в этой ветке подразумеваются DOS-базированные ОС семейства 9х.
Но если нужны бенчмарки именно для DOS , их есть у меня

goodman4444

Цитата:

Но если нужны бенчмарки именно для DOS , их есть у меня

Спасибо, скачал, чтобы не искать. Как раз освободился один из компьютеров с виртуальной машиной. Если всё это запустится на современном АМД в чистом DOS, можно будет посмотреть на производительность под виртуальной машиной и на железе.

Перед тем как сообщить радостную новость, хочу напомнить что я очень старый посетитель этого форума, потерявший из за периодических брыков здесь свои старые учётки несколько уже раз. terenty79 может кто помнит ещё. Но не будем о грустном, а перейдём к радостному событию. Этот пост последний , который я делаю вообще на любой моей ретросистеме, и уже через неколько часов весь многочисленный металалом что я героически скопил отправиться на помойку, а я сяду исключительно за свой новый ноут с десяткой внутри. Так что я больше не ёжик, грызущий кактусы, а обычный современный бытовой юзер, ну и соответственно пастись в данной теме, которая была наиболее близка мне, уже смысла нет. Вообщем всем -примите мои поздравления, одновременно с соболезнованием. прощайте. Надеюсь пидорасты, и я не побоюсь этого слова даже под страхом отлучения и бана, современные разработчики софта, а в особенности многие опенсурсники, которые есть настоящее быдло, сброд, форменное хамло, а по сути дела обычные тупорылые овощи и канонические лентяи, которым просто от рождению повезло разбираться в коде чуть больше основной массы обычных людей, работающих в других отраслях человеческой жизнидеятельности, вас не смогут унизить и растоптать своей прихотью . а мне вот теперь никакого via с3, athlonxp, win9x, дос, 3dfx и всего подобного прочего, ну и извиняйте если уж что, ещё раз всем пока и героических подвигов!

Цитата:

хаймем умеет по разному, обычно именно так и делает.

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

Цитата:

"то вот опкодов для трехрежимного исполнения" т. е. в эпоху х32 успели занять все свободные биты сетки микрокоманд мыслимых для x32?

да. для х64 задействовали часть опкодов, использовавшихся в 286. плюс убрали селекторы совсем, хотели ограничиться флагами разграничения доступа в таблицах страниц... но оказалось, что тогда невозможно сделать виртуализацию (я же говорил - рожали сразу две мамки? одна то вроде как сумела виртуализировать без сегментов, а вторая - нет). поэтому быстренько прикрутили селекторы обратно, но как они там работают - никто не знает. а самое смешное, что хотя 32 битный код и может работать в х64, но только в линейной форме, PE only. LE/LX с его call 1234:abcdef56 - никак.
это я не говорю про эпопею с прикручиванием AVX, для которых префикс использует опкоды бывших LDS и LES. те в реальном режиме АВХ никак не пощупать... как там с этим разбирается 32хбитный LINPACK with AVX - хз... теоретически оно не должно работать....
плюс после них еще два три байта. зато теперь у х86 появилось еще одно пространство опкодов... интересно, что придумают, когда и его исчерпают...

Цитата:

вот а что им мешало сделать комманды больше 15 байт?

ну типа декодер надо переделывать... и наверняка пропадет реальный режим. туда ему и дорога...
вот в арме один 4 байтовый опкод умудряются делать две операции над тремя регистрами... и там почти все опкоды 4 байтовые.
это я к чему говорю. RISC ядро современных х86 чудовищно мощное (слышали небось про Эльбрус, какой он невъепенно мощный в нативном VLIW? вот и тут то же самое, только еще круче за счет частот и вылизанности ТП). но оно задавлено этой многослойной луковицей. а без этой луковицы - х86 никому и не нужен. скорость набора текста человеком что на Z80, что на 386, что на й7, что 1 мгц нокии, что на 2 ггц арме с 4 ядрами - одинакова.


Добавлено:
IFkO
Цитата:

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

тут немного другой предел... термодинамический, квантовый.
представь, что у нас 1 бит, и нам нужно провести с ним простейшую операцию - НЕ. сколько энергии нужно затратить на это? пусть один такт, и один бит. сколько энергии надо, чтоб переключить бит?
не меньше, чем квант теплового шума при данной температуре.
это 0,02 эВ при комнатной температуре. в реальности, конечно, больше на порядки. но не менее 0,02 эВ на переключение одного бита.
вот прям щас у меня ЛИНПАК выдает чуть больше 100 гфлопс. это с числами 64 бит с плавающей точкой.
те 1 флопс - минимум 64 переключающихся бита в секунду. пусть 100. итого имеем 10 трлн битовых операций в секунду. это если все флопсы сводятся к одним только НЕ, тикающим один раз. в реальности, конечно, больше на порядки. но не менее ТэВ/с = 10^12*10^-20 Дж/c = 10^-8 Вт. меньше этого мой проц, выполняя эти вычисления, кушает не может даже теоретически. в реальности он ест чуть больше 100 Вт.

что говоришь? есть запас в 10 млрд раз? нема у пана атамана запасу...
1 - на переключение одного бита вряд ли хватит и десятка тепловых квантов - нужно перезарядить емкости. множим на 100,
2 - логические операции не ограничиваются НЕ. значит, за такт выполняется намного больше переключений вентилей, возьмем 10 - и это на один бит результата,
3 - на один вентиль в АЛУ приходится минимум 10 транзисторов,
4 - у нас не один 64 битный регистр, дергающийся миллиарды раз в сек. их сотни 128-256 битных, плюс компараторы. множим на 1000,
уже имеем запас всего в 1000...
5 - помимо этих 1 млн непосредственно считающих транзисторов, в процессоре есть декодер, планировщик, кеши, прочее. да, оно в основном спит, и тикает не на 4 ггц, но... их 2 млрд. и они все периодически хотят жрать!
6 - утечки...
так что нема у пана атаману золотого запасу...

"да. для х64 задействовали часть опкодов..." Ну что сказать? Зае... А ведь можно было же ещё на этапе x16 -> x32 запланировать какой-нибуть бит в каждом байте или состояние битов в целом байте как указатель расширения опкода на следующие байты (см. например UTF-8), что дало бы возможность теоретически бесконечно безболезненно наращивать число опкодов. Величайшая лажа от Intel-а короче.
А так, мало того что по сути похерили x16 - ладно, старый, почти забытый, так ещё выходит покоцали и x32. А что они будут делать когда встанет вопрос x64 -> x128? Итого выходит да: х86 капец не за горами. Такими темпами однажды встанет вопрос скажем так необходимости вернутся к 8080 (или когда всё там ещё было ровно и красиво) и по умному переделать всё что позже.

"что сегменты ds/es переведены в 32 лимит" да и некоторые ньюансы поста, типа этой цитаты, остались непонятны, но понял помоему главное: я как-то до этого считал что можно творить все что угодно, но пока не делаешь LMSW механика работы процессора не меняется. А выходит - меняется.

п.с. В таком случае чтож. Признаю 98й, как архитектуре как таковой, на х86 которая сегодня, неговоря уже о её о будущем, ничего не светит т. к. морально нет толку городить приближённую к железу ОСь с обширной совместимостью на таком кривом и мутном гавне.

Ну и с другой стороны х64 программа под 98й не нереальна по определению, как и под ДОСом. Да и вся ясность с неподдержкой 64битной винды дров от ней-же 32битной, да и неработоспособностью некоторых 32битных программ под 64битной виндой (а с Линуксом в таком случае я так понимаю то-же самое, просто не так заметно т. к. там надо перекомпилировать весь пользовательский софт следом за каждой модификацией нутра оси)

Сильно сильно благодарю.

MERCURY127
Ты теоретически рассуждаешь. Практика же от этих цифр весьма далека. И в ней потребляемая мощность определяется совершенно иными соображениями, далёкими от двоичной логики, но близкими к тривиальной аналоговой электротехнике: дистанцией пробега электронов в проводнике и его сопротивлением. А вот если мы неожиданно перейдем на квантовые компьютеры, тогда твои расчеты очевидно будут намного ближе к реальности. Пока же КПД "логики" примерно как у паровоза или лампы накаливания, у которых полезная работа является скорее побочным эффектом совершенно других процессов. КПД паровоза вполне можно повысить на нынешнем уровне технологий, но только тепловоз всё равно эффективнее.

IFkO

Цитата:

Пока же КПД "логики" примерно как у паровоза или лампы накаливания,

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

IFkO

Цитата:

Пока же КПД "логики" примерно как у паровоза или лампы накаливания, у которых полезная работа является скорее побочным эффектом совершенно других процессов.

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

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


Добавлено:
sergne80

Если не секрет, утомило тратить на ретро-компьютеры много времени, проблемы с поддержанием железа в рабочем состоянии одолели в техническом и финансовом смысле или просто надоело?