.

Если все таки кто-нибудь узнает ответ на мой вопрос, то будет интересно его услышать.

QUOTE (AmbassadorKosh @ Nov 15 2006, 21:33)

Если все таки кто-нибудь узнает ответ на мой вопрос, то будет интересно его услышать.

Разве я на него не ответил?

Никак, поскольку размер указателя это лишь верхушка айсберга.

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

QUOTE (Nox Metus @ Nov 13 2006, 10:00)

Наверное, я отстал от жизни. В случае процессоров с не x86 архитектурой, например Itanium, все понятно. А вот зачем нужна 64битная надстройка над x86? Какие преимущества дает и почему? Я вижу только недостатки: увеличивается длина указателя в два раза. Эту существенно увеличивает объем необходимой памяти для хранения указателей и количество операций с ней. В современных ООП языках, кроме C++, объекты хранятся по ссылкам, так уж получилось. Все это должно приводить к существенному оверхеду, т.к. память значительно медленнее процессора. Разъясните, пожалуйста.

По аргументации здесь и далее в дискуссии не могу предположить, что возможность адресации далеко за 4G выпала из рассмотрения. Поэтому в свою очередь прошу обяснить мне, почему одна эта причина по-вашему не оправдывает существования x64? Я по-простому считал так - есть ОЗУ на 8G и больше - надо с этим считаться. x64 vs "например Itanium" наверное имеет право быть, кроме ценовых причин, за-ради совместимости с x86 - ориентированным софтом.

QUOTE (Nox Metus @ Nov 16 2006, 11:12)

Потому что IA-32 умеет адресовать 64GB памяти. Так что одна эта причина не оправдывает.

Даже если принять 36-разрядную адресную шину продвинутых пеньков за полноценную 64Г-ю адресацию, что скажите про хранение и обработку 36-битных указателей? Во всяком случае разработчиков WIN32 это похоже не вдохновило, и в итоге я получаю на процесс те же 4Г брутто. То что сама ось управляется с 64Г, конечно радует, но вдруг захочется и самому массив на 5-6Gb определить. Почему нет, если ОЗУ позволяет? Вот даже на этой ветке объявились желающие. Вроде WIN64 здесь идет на встречу.

QUOTE (Nox Metus @ Nov 16 2006, 13:20)

одно лишь увеличение адресуемой памяти выше 4Гб нет, не оправдывает. Линейность адресуемого пространства - это да, аргумент. С натяжкой.

Что ж, это мнение, спорить нет смысла. Я полагал очевидным, что речь шла о линейном АП. Для меня кардинальное увеличение АП самоценно. По задачам может Вам будет интересно http://www.internetaccessmonitor.com/rus/p...it-Good-E12.php , хотя это всего лишь заявка, судьбу релиза не знаю.

QUOTE (Nox Metus @ Nov 16 2006, 13:20)

mer привел в пример задачу расчета магнитного поля детектора Atlas. И Gesser, The Cat привел в пример задачу анализа сетевого трафика в реальном времени. Первая задача узкоспециальна и массвого внедрения IA-32e не оправдывает, для нее можно и Itanium найти. Вторая задача, да, аргумент.

Не скажите, пример детектора Atlas был дан как иллюстрация проблемы. На самом же деле, 3D расчеты упираются в ограничение по памяти и в массовом случае. Простая оценка показывет, что при расчете конструкции с числом элементов 500х500х500 (это чтобы отойти по минимуму от обсуждения вопросов точности расчета как такового) при памяти, скажем, 100 байт на элемент, требуется больше 10 Gb.

QUOTE (den @ Nov 13 2006, 12:53)

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 по ссылке недавно, видно что в винде есть тоже "сплит" и ключик /3G https://academ.club/html/emoticons/wink.gif

QUOTE (Nox Metus @ Nov 17 2006, 00:47)

QUOTE (mer @ Nov 17 2006, 00:37) На самом же деле, 3D расчеты упираются в ограничение по памяти и в массовом случае. Меня все-таки берут сомнения насчет их массовости https://academ.club/html/emoticons/smile.gif. Задачи эти все-таки научные. Сможете навсидку пример где такие расчеты нужны в народном хозяйстве https://academ.club/html/emoticons/smile.gif? Я имел в виду обычные конструкторские расчеты (механические, тепловые, электрические), ну и всякие гидро-авиа-магнитные.

QUOTE (Nox Metus @ Nov 16 2006, 17:07)

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

Собственно, Вы почти точно сформулировали. Основная ниша для 64разрядной архитектуры - корпоративные сервера баз данных.

 

Ну и разные частные случаи - САПРЫ СБИС, например. А так, для основных задач никакого существенного скачка, сравнимого с переходом от 16 к 32-разрядной - не будет.

По большому счету преимущество только в том, что регистры стали больше. Но есть и минус, действительно указатели стали в 2 раза больше, а это значит что при одном и том же размере кэша их стало меньше храниться по сравнению с 32 битным процессором. Конечно увеличился объем памяти которую можно адресовать но опять же это нужно далеко не всем приложениям.

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

A по моему вы не до оцениваете ограничения 2Г

 

Во-первых, файловые системы (в том числе и у массового пользователя) перешагнули этот рубеж очень давно и сейчас на 32-битных системах весят на костылях типа long long. И еще, Я встречал довольно много програм, которые даже не задумывались об 2Г, уперлись в это ограничение. Конечно, в первую очередь сервера, то прокси обрежить образ dvd, то syslog не смог записать больше 2Г. А ведь x86 самая распространенная платформа и в этом сегменте тоже, так что opteron наше всё https://academ.club/html/emoticons/smile.gif А попробуй сохранить тот же dvd образ через IE - думаю будут проблемы, хотя ФС давно уже 64битные. Кстати, довольно частая задача для end-user - обработка статистики, и тут легко выходим за 2Г!

 

Можно конечно бороться с каждой прогой, ставя ее на костыли - но всё же наверно проще перейти на 64бита и больше не думать об этом (до следующих бит https://academ.club/html/emoticons/smile.gif )

 

Плюс к тому же криптование и компрессия, где производительность возрастает ровно в 2 раза.

 

P.S. Посмотрел на свой комп, да прог которым реально нужно было 64-бита не так много, но за те которые используют - я уверен ;), а там глядишь и остальные подтянуться - по объему https://academ.club/html/emoticons/smile.gif

 

 

QUOTE (Nox Metus @ Dec 7 2006, 06:40)

В огороде бузина, а в Киеве дядька.

Так это о чем вы? "дядя" https://academ.club/html/emoticons/wink.gif

QUOTE (Nox Metus @ Dec 7 2006, 22:59)

Если под словом "вы" вы имели в виду меня, то посылка ложная.

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

без заморочек насчёт того что надо использовать long long или uint64_t . это видно на примере многих файлух : vfat, все ранние fat'ы. iso9660 (cdfs), да и на dvd сейчас (кстати там такая же файлуха iso9660) файлик больше 4-х гигов не запишешь.

а потом когда программа-файлуха-операционка-ядро получает распространение, начинаются всякие костыли, заплатки и -D_LARGE_FILES.

 

такого бы не было изначально если бы long был бы 64-битным. опять же просто для примера. https://academ.club/html/emoticons/wink.gif

 

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

QUOTE (Nox Metus @ Dec 7 2006, 23:56)

Мне казалось, что операционные/файловые системы "по наитию" не создаются.

ну и неправильно казалось. почитайте историю linux, первые maillist'ы, сообщения линуса, историю dos-m$-winblowz https://academ.club/html/emoticons/wink.gif

в остальных не очень силён. но там всё триста раз менялось. и от первоначальных требований ничего скорее всего не осталось. https://academ.club/html/emoticons/smile.gif

 

QUOTE (Nox Metus @ Dec 7 2006, 23:56)

Не могли бы вы обосновать или пояснить свое утверждение про создание операционных и файловых систем "по наитию" и "интуитивно"?

то есть вы действительно считаете что ядро/файлуха к разрядности процессора не имеет отношения ?!! вы прицепились к словам по-наитию-интуитивно, хотя они были написаны через дефис, что в означало по разным причинам, whatever. может это вы обьясните, почему программист/команда должна использовать 64-битные типы везде если архитектура 32-х битная ? или того хуже 8,16, или какой-нить embedded девайс ? или почему программисты должны делать какие-то закладки к расширению, если расширения не предвидится. да и опять же, расширение размерности имеет свойство плохо сказываться на производительности.

 

а ещё, удачные проекты имеют свойство эволюционировать и расширятся, например. https://academ.club/html/emoticons/smile.gif

 

неужели надо дальше разжёвывать ??

QUOTE (Nox Metus @ Dec 8 2006, 00:22)

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

ок, дальнейшего обсуждения не будет. https://academ.club/html/emoticons/cool.gif делов-то. ваша песочница, начальник. играйте в ней сами https://academ.club/html/emoticons/wink.gif