Слава Фреду!

Fred rock's!!! Придётся седня сразу два образа тянуть (x86 и X86_64(slackware))

Ура. Наконец-то это грандиозное событие свершилось.
Слава Патрику и Фреду! Храни их Г-сподь!

Слака рулит нипадеццки! Патрик и Фред -- боги!

Поздравляю, slackware 64bit коммунити! Единственное, что совершенно не понятно - это названия дисков, притом отсутствуют всякие пояснения...

УРА! Патрик и Фред рулят!

Мы все ближе к ПервоСлаке !

ура господа!

>Придётся седня сразу два образа тянуть (x86 и X86_64(slackware))

нафига? там же разницы никакой, у кого не спосиш - прибавление производительности 0.01%

толку то?

Для серверов с ораклом(например) x86_64-платформа даст выигрыш из-за большего количества адресуемой памяти :)

> прибавление производительности 0.01%

Мне говорят 10-20%, а 0.01 - это как считали?

отож слухами полнится индустрия x64, SLI, ATA-2 какое ещё безполезное лекарство от тормозов за наши деньги предложат нам маркетологи?

Люди, объясните кто-нить мне, неграмотному, что такого в 64-х битах, что это нужно публиковать такой помпой и клепать по этому поводу новые дистры?

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

Переход с16 бит на 32 давал прирост скорости куче аппликух, int32 юзается гораздо чаще, чем int16. int64, ИМХО, юзается крайне редко (кроме упомянутых случаев).

Чем еще, кроме int64 и линейной адресации больших объемов памяти могут похвастаться 64-х битные AMD-шники? Про sse3 и повышенные частоты я знаю.

Кроме того, крайне интересно, какие глюки могли быть (а о проблемах в софте на 64-битных платформах орут чуть не каждый день)? Что, был в исходниках integer, который подразумевался как int32, а теперь integer = int64 и прога приказала долго жить в новых условиях? Или еще что?

P.S. Не флейма ради, реально интересно.

Высказываю свое мнение:

1. Архитектура amd64 это не только 64-битные регистры и команды работы с ними, это еще и дополнительные регистры общего назначения, использование которых позволяет писать более эффективный код, и дает прирост от 10 до 20% скорости (уменьшение т.н. "register pressure").

2. Естественная реализация и манипулирование числами с плавающей точкой - также имеющими 64 бита. Появилась возможность хранить и обрабатывать их на ALU, а не FPU. У Athlon64 впечатляющая производительность single-SSE2 операций (как целочисленных, так и с плавающей точкой).

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

4. Atlon64 это еще и встроенный контроллер памяти и соединение типа "точка-точка" с системной периферией --- HyperTransport (в том числе и с другими процессорами) - возможность построение эффективных (более чем 8 процессорных систем) + упрощение системной логики и прирост производительности на участке процессор--память.

> 1. Архитектура amd64 это не только 64-битные регистры и команды работы с ними, это еще и дополнительные регистры общего назначения,

>2. Естественная реализация и манипулирование числами с плавающей точкой - также имеющими 64 бита. Появилась возможность хранить и обрабатывать их на ALU, а не FPU. У Athlon64 впечатляющая производительность single-SSE2 операций (как целочисленных, так и с плавающей точкой).

Использование этого требует изменений в софте, а не дистрах.

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

На сколько я помню, хрен где это используется. Но защита памяти средствами процессора - уже привилегия дистра, это да.

> 4. Atlon64 это еще и встроенный контроллер памяти и соединение типа "точка-точка" с системной периферией --- HyperTransport (в том числе и с другими процессорами) - возможность построение эффективных (более чем 8 процессорных систем) + упрощение системной логики и прирост производительности на участке процессор--память.

Это вообще к софту никакого отношения не имеет.

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

3 и 4 пункт никакого отношения к 64битам не имеет, у меня 32ух битный Semptron K8, и это там тоже реализованно!

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

Кстати в 1ом пункте упомянуты некие новые регисты общего назначения, так что помимо обычных AX, BX и т.д. в 64 процах появились регистры ZX и XX? или как обстоит дело? скорее всего регистры все теже и остались, только стали 64 битными. Короче давайте дальше дискутировать, на тему... 64 бита, а оно надо?

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

я ещё понимаю новел и микрософт, они пытаються продать один и тоже код скомпилированный под маркой 32б и 64б, но смысл это городить в СЛАКЕ?

там же сорцы, какой ключик поставил, столько тебе и битный софт от 8 до 64 бита! выбирай, или я что то не понимать?

Ты что-то не понимать. Разделяемые библиотеки должны также совпадать по форматам. Так что либо все статически, либо никак.

Повторяю. Весь сыр-бор только изи за поддержки разделяемых библиотек, и специфических возможностей 64-битного режима. Кроме того, некоторые программы (в частности ядро) _должны быть_ модифицированы, чтобы исползовать 64 битность.

> Кстати в 1ом пункте упомянуты некие новые регисты общего назначения, так что помимо обычных AX, BX и т.д. в 64 процах появились регистры ZX и XX? или как обстоит дело? скорее всего регистры все теже и остались, только стали 64 битными. Короче давайте дальше дискутировать, на тему... 64 бита, а оно надо?

General-purpose registers. For the 16-bit data size, these are AX, BX, CX, DX, DI, SI, BP, and SP. For the 32-bit data size, these are EAX, EBX, ECX, EDX, EDI, ESI, EBP, and ESP. For the 64-bit data size, these include RAX, RBX, RCX, RDX, RDI, RSI, RBP, RSP, and R8-R15. http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24594...

Давайте все же Вы что-нибудь почитаете по устройству процессоров Athlon64. А дискутировать будем после.

>>нафига? там же разницы никакой, у кого не спосиш - прибавление производительности 0.01%

Сотая сотой? Не ошибся?

>>нафига? там же разницы никакой, у кого не спосиш - прибавление производительности 0.01%

>Сотая сотой? Не ошибся?

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

>Использование этого требует изменений в софте, а не дистрах.

Не подскажете какого ? ;) Или вы думаете что софт на асме написан ? ;)

hint: простая пересборка под TARGET=x86_64 позволяет заюзать вышеуказанные фичи.

2anonymous (*) (16.09.2005 13:13:10)

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

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

А у меня 2-й год крутятся в кластере в количестве 8 штук.

По производительности зависит от задачи. На некоторых есть прирост до 40% На текоторых даже лёгкий проигрыш (говорят за счёт более длинных указателей... но ImHO несовершенство оптимизации компилера под x86_64 по сравнению с вылизанным ia32 гораздо более вероятная причина)

Для начала надо cross-compiler с окружением собрать, чтобы он мог держать такой TARGET ;)

Народное творчество

>Для начала надо cross-compiler с окружением собрать, чтобы он мог держать такой TARGET ;)

Это проблема чтоли ? ;)

У меня их 3 штуки стоит (x86,ARM,x86_64)

PS: Какой нафиг в SLAMD64 кросскомпайлер ? Ну разве что в x86.

>>Не подскажете какого ? ;) Или вы думаете что софт на асме написан ? ;)

Некоторые несознательные товарищи вместо того чтоб юзать +сайзоф писали "+32". При переходе на 64 разряда глючит "нипадецки" и также неожиданно, это наверно занимает 90% всех глюков. К тому же частично и на асме что-то писалось.

В целом согласен. Большинство софта компилится без проблем.

Народное творчество

>Некоторые несознательные товарищи вместо того чтоб юзать +сайзоф писали "+32". При переходе на 64 разряда глючит "нипадецки" и также неожиданно, это наверно занимает 90% всех глюков. К тому же частично и на асме что-то писалось

Для этого как раз есть руки. Если бы действительно можно было бы всё тупой перекомпиляцией сделать, не нужны бы были никакие SLAMD64

> PS: Какой нафиг в SLAMD64 кросскомпайлер ? Ну разве что в x86.

Я про x86 и говорю :) Коречно же, для slamd64 кросс не нужен.

>Big thanks to:

>The Gentoo x86-64 and Debian Pure64 projects for GCC 3.4, Linux 2.6, and x86-64 compatability patches for various applications

Позор слакварщикам! Самим слабо создать 64 версию.

А зачем изобретать велосипед?
Я, например, некоторые патчи из генту беру :)

а я скрипты из Фряхи...

shame on me :)