Опубликовано 13 ноября, 200619 г. comment_3077619 Вообще говоря если писать бугалтерские программы и веб-дизайном заниматься то оно конечно нафиг надо, а если что то посложнее делать, то пожалуй преимущества есть. Например задачи с большим количеством вычислений, где сетки в 32 попросту маловато. Кроме того давайте вспомним что ООП не единственный подход в программировании, и не все задачи он решает https://academ.club/html/emoticons/smile.gif А ПК все таки универсальная система. 64 битную систему не юзал еще, но думаю 32 битовый режим там поддерживаеться, так что исползуйте старый компилятор и все ок будет с памятью https://academ.club/html/emoticons/smile.gif Жалоба
Опубликовано 13 ноября, 200619 г. comment_3077705 нормальная адресация больше 872M оперативы ? https://academ.club/html/emoticons/smile.gif без всяких 1/3 2/2 сплитов? ну и в общем, больше 4G. преимущества и версии тоже хотелось услышать. я пользовался amd64 каким-то как юзер и портировал софт. никакой фантастического взрыва производительности даже близко нет https://academ.club/html/emoticons/wink.gif upd: http://en.wikipedia.org/wiki/64-bit Изменено 13 ноября, 200619 г. пользователем Гость Жалоба
Опубликовано 13 ноября, 200619 г. comment_3077942 QUOTE (Nox Metus @ Nov 13 2006, 10:00) Наверное, я отстал от жизни. В случае процессоров с не x86 архитектурой, например Itanium, все понятно. А вот зачем нужна 64битная надстройка над x86? Представлять x86-64 как надстройку над x86 неправильно. Это *другая* архитектура, которая (в отличие от Итаниума или Альфы) умеет быстро выполнять x86 код. Соответсвенно, преимущества и недостатки такие же как у любой другой 64-битной архитектуры: быстрое целочисленное умножение больших чисел (читай: криптование), нормальная работа с большой памятью, увеличенное потребление последней, остальное по мелочи. Жалоба
Опубликовано 13 ноября, 200619 г. comment_3077973 QUOTE (dura @ Nov 13 2006, 11:48)нормальная адресация больше 872M оперативы ? https://academ.club/html/emoticons/smile.gif без всяких 1/3 2/2 сплитов? Немного занудства: нормальный сплит -- это как раз 3G для задач, т.е. с адресацией все в порядке, а 896M это ``low memory'' при нормальном сплите (1G - 128M space for bounce buffers). Но это все только для линукса, не забывайте, существуют и другие ОС https://academ.club/html/emoticons/shy.gif Жалоба
Опубликовано 13 ноября, 200619 г. comment_3079115 В своё время, я участвовал в проекте, которому позарез нужно была адресация на дофига-дофига оперативки и офигенное быстродействие. И постоянно была необходимость работы с long long. На 32 битной арзитектуре всё это хозяйство тормозило как чёрт знает кто.... Правда, памяти оно жрало тоже как слон банные веники https://academ.club/html/emoticons/sad.gif Жалоба
Опубликовано 13 ноября, 200619 г. comment_3081988 Интересно, а как будут называться 64-разрядные регистры? Интересуют их имена, т.е. 8 р. AL и AH 16 р. AX 32 р. EAX 64 р. ... Жалоба
Опубликовано 13 ноября, 200619 г. comment_3082294 QUOTE (den @ Nov 13 2006, 12:53) Но это все только для линукса, не забывайте, существуют и другие ОС https://academ.club/html/emoticons/shy.gif 98-ая гиг оперативы видела тоже как 896M https://academ.club/html/emoticons/wink.gif Жалоба
Опубликовано 14 ноября, 200619 г. comment_3082686 QUOTE (Nox Metus @ Nov 13 2006, 13:44) QUOTE (den @ Nov 13 2006, 12:44) Представлять x86-64 как надстройку над x86 неправильно. Это *другая* архитектура Да ну же. Вы что-то путаете. Они даже описываются интелом в одном документе. "Другая" не противоречит моему утверждению: это надстройка над старой архитектурой. Почитайте "Intel® 64 and IA-32 Architectures Software Developer’s Manual" SKU#25366521. Обе "разные" архитектуры базируются на одной и той же микроархитектуре ядра процессора, что, собственно, и позволяет быстро исполнять 32битный код. Процессору просто на уровне ядра начхать на 32/64 битность. ээ... я думал вы рассматриваете с точки зрения программиста. Ему какая разница как там транзисторы соединены? Мой пойнт был в том, что *программная* архитектура (ABI например) другая, в отличии от всяких надстроек, типа MMX. Жалоба
Опубликовано 14 ноября, 200619 г. comment_3082689 QUOTE (dura @ Nov 14 2006, 00:34) QUOTE (den @ Nov 13 2006, 12:53) Но это все только для линукса, не забывайте, существуют и другие ОС https://academ.club/html/emoticons/shy.gif 98-ая гиг оперативы видела тоже как 896M https://academ.club/html/emoticons/wink.gif Вы напрасно изволите линукс обижать ;) Гиг памяти он видит как гиг (если ядро в HIMEM собрано), просто 896M будет low, а 128M high. :-) Жалоба
Опубликовано 14 ноября, 200619 г. comment_3083206 Пример задачи, для которой не хватает 2 GB: расчет магнитного поля детектора Atlas. При общем размере детектора порядка 25 метров некоторые детали нужно посчитать с сантиметровым разрешением. Жалоба
Опубликовано 14 ноября, 200619 г. comment_3083651 QUOTE (Nox Metus @ Nov 14 2006, 11:58) Что такое ABI? Если я правильно понимаю Application Binary Interface. В связи с этим возникает интересный вопрос. Вот у нас библиотека скомпилированная для 32битной архитектуры, а мы хотим заюзать её на 64 битной. Теперь предположим, что рантайм (ну допустим glibc) у нас слинкован динамически, как нам гарантировать, что все не развалится? Т.е. допустим заюзаются имеенно те функции которые надо. С не С++ манглирования имен нет. Так что нам делать, что бы достичь обратной совместимости, что бы у нас из 32битного кода не позвался маллок который возвращает восьмибайтный указатель? // В маллок вставлять проточки, чтобы он каким-то Образом узнал в каком редиме проц? Это вообще возможно? Жалоба
Опубликовано 14 ноября, 200619 г. comment_3087018 QUOTE (AmbassadorKosh @ Nov 14 2006, 13:21) // В маллок вставлять проточки, чтобы он каким-то Образом узнал в каком редиме проц? Это вообще возможно? если есть битик в LDT/GDT, почему нет ? https://academ.club/html/emoticons/smile.gif деталей не знаю, честно признаюсь Жалоба
Опубликовано 14 ноября, 200619 г. comment_3087627 QUOTE (AmbassadorKosh @ Nov 14 2006, 13:21) QUOTE (Nox Metus @ Nov 14 2006, 11:58) Что такое ABI? Если я правильно понимаю Application Binary Interface. В связи с этим возникает интересный вопрос. Вот у нас библиотека скомпилированная для 32битной архитектуры, а мы хотим заюзать её на 64 битной. Теперь предположим, что рантайм (ну допустим glibc) у нас слинкован динамически, как нам гарантировать, что все не развалится? Т.е. допустим заюзаются имеенно те функции которые надо. С не С++ манглирования имен нет. Так что нам делать, что бы достичь обратной совместимости, что бы у нас из 32битного кода не позвался маллок который возвращает восьмибайтный указатель? // В маллок вставлять проточки, чтобы он каким-то Образом узнал в каком редиме проц? Это вообще возможно? Да, именно в этом и проблема. Соглашения о передаче нараметров, содержимое того же vtable, и т.п., это все относится к ABI и они отличаются для x86 и x86-64. Нельзя простыми методами вызвать процедуру скомпилированную под одну архитектуру из другой без серьезных извратов, типа написания врапперов, которые будут все переупаковывать. Поэтому это разные архитектуры, а то что x86 команды могут встречаться среди x86-64 -- несущественная деталь. Жалоба
Опубликовано 14 ноября, 200619 г. comment_3087751 QUOTE (Nox Metus @ Nov 13 2006, 16:23) Хорошо. А можно подробнее про задачу, которая решалась в проекте? Реалтаймовый анализ сетевого трафика. Канал гигабит при полной загрузке. Там просто получалось дофига инфы на обработку, которая во время процесса обработки расла в геометрической прогрессии https://academ.club/html/emoticons/smile.gif В частности, приходилось использовать в качестве 64 разрядные индексы при хранение данных, ибо 32 бит просто-напросто нехватало. Ну и, соответственно, постоянно были операции с 64 битными integer'ами. Опять же, структуры данных были весьма здоровыми и их нет-нет да и приходилось постоянно копировать, перемещать и всячески оперировать с ними - так что требовался как можно более жирный memcpy. Так же местами сильно спасала возможность битшифта на 64 битном поле - вычислений бо там тоже хватало. Да там капец был... рассчёт шёл на аппаратную базу с минимумом 4 гектара оперативки, терабайтом винчестерного пространства и 4мя процами 64ёх битными (AMD, разумеется. Intel стоил бы как самолёт). Приложение просто было офигенно энергоёмким. 64 бита для него было естественным настолко же, насколько для Adobe Photoshop является 32 бита (представляю я себе обработку true color на 16 битной платформе https://academ.club/html/emoticons/blink.gif ). Жалоба
Опубликовано 15 ноября, 200619 г. comment_3088031 QUOTE (Nox Metus @ Nov 15 2006, 02:47)То что эти архитектуры разные для 64битного режима и 32битного - это лишь констатация факта и никак не следует из ваших посылок. Констатация, безусловно, верная. Честно говоря, не понял. https://academ.club/html/emoticons/unsure.gif QUOTE (Nox Metus @ Nov 15 2006, 02:47)ТНо я то говорил об архитектуре процессора и его execution environment. Каким образом из констатации факта отличий в архитектуре языков высокого уровня следует отрицание моего утверждения: "64 битный режим в x86 является расширением архитектуры IA-32"? Ну, выше я высказывал предположение, что речь идет о программой модели, и поскольку Вы не опровергли его, я решил что мы говорим об одном и том же. Впрочем, если вопрос лишь в названии типа родства x86 & x86-64, то предлагаю замять его. https://academ.club/html/emoticons/beer.gif Жалоба
