To Die-Hard:

> Самая большая проблема с программами, в которых ПРОПИСАНО, что в int 4
> char'а или 32 бита. Например, int *p=calloc(1,4)

Ну, это уж руки из попы просто надо программистам доставать... То есть про sizeof(), по-моему, написано просто в любой мала-мальской книжке по С.

> Вторая большая проблема с программами, считающими, что int = long.

Ну это ваще! Этому же учат на первом курсе любого технического вуза! Или нам софт с открытым исходным текстом филологи пишут? ;)

> разница поинтеров может не поместиться в int.

Как это -- "разница поинтеров". В смысле "p1-p2"? Тогда зачем её пихать в int? Не всосал...

> Проблема, специфическая для g++: на 32 битах bool=int
> (грубо говоря), а на 64 битах sizeof(bool)=8 (!)

А у меня sizeof(bool)=1. Может у Вас gcc какой-нибуть не gcc-шный. Вот и не gcc-ит ;) У меня версия 3.2.1 20021119.

2phicus (*)

> А у меня sizeof(bool)=8

Простите, на каком процессоре? У меня 1.

anonymous (*) (2003-09-04 17:56:51.665238):
> Адын, всегда адын.

Действительно, поправили.

$uname -s -m
Linux i686
$g++ --version
g++ (GCC) 3.2
$./test
1

$uname -s -m
Linux i586
$g++ --version
2.95.3
$./test
4

$uname -m -s -v
OSF1 1091 alpha
$g++ --version
2.95.3
$./test
8

$uname -m -s -v
OSF1 1229 alpha
$g++ --version
2.95.2
$./test
8

2phicus (*)

Проверил сейчас на не-x86 машине с оч-чень древней архитектурой. Die-Hard по всей видимости имел в виду g++ 2.95.3. Но там тоже у нас не было проблем при переходе с 32 к 64. =4

2Die-Hard

1 на x86 и возмутителе спокойствия. 3.3.

2All

Вопрос в том что максималисты, выдающие вот такие перлы как "кто ж найдется на покупку такого говна" показывают свой напрофессионализм и прыщавость. Поэтому этого господина здесь и освистали.

Помню, как в 1994 году пытались пнуть фирму "Интел", допустившую глюк в Pentium. Смеху было! Ну и кто сейчай самый массовый процессор? То же и с Itanium.

>Действительно, поправили.

Умение признавать неправильность в высказываниях - признак профессионализма. Так что респект.:).

>>Сcылочку дайте пожалуйста.
>Зайди на сайт HP или spec.org и посмотри.

http://www.jscc.ru/cgi-bin/show.cgi?path=/hard/mvs1000m.html&type=2
Я думаю никому не надо напоминать, что советский - значит лучший?

>Я думаю никому не надо напоминать, что советский - значит лучший?

"Да он же ламповый ... !!! " (c) народный анекдот про самые быстрые процы ;)

>Ну и кто сейчай самый массовый процессор? То же и с Itanium.
Ну мля, ты сравнил пень и итаниум. Пень сразу был нацелен на десктоп а у итаниума таких планов даже нету в силу разных причин. Так что кто там на серверном рынке победит еще большой вопрос.

>Пень сразу был нацелен на десктоп а у итаниума таких планов даже нету в силу разных причин.

Читать умеем или мне по телефону позвонить малограмотному и перевести?

http://www.intel.com/ebusiness/products/workstation/index.htm

The Intel® Itanium® 2 processor uses Explicitly Parallel Instruction Computing (EPIC) and 64-bit architecture to deliver world-class performance to high-volume workstations.

phicus (*) (2003-09-04 18:28:51.461318):

>> Самая большая проблема с программами, в которых ПРОПИСАНО, что в int 4 char'а или 32 бита. Например, int *p=calloc(1,4)

>Ну, это уж руки из попы просто надо программистам доставать... То есть про sizeof(), по-моему, написано просто в любой мала-мальской книжке по С.

Согласен. Тем не менее данный пример НЕ нарушает POSIX.

Кстати, в том примере я лажанулся. Он БУДЕТ корректно работать на 64 битах! Проблемы возникнут при использовании long, а не int.

Далее: пример из "Хрестоматия по программированию на Си в Unix, Андрей Богатырев, Библиотека М.Мошкова:"

i = (i << 1)|(i >> 15); /* ROL */

ПисАлось для 16 бит, поэтому даже на 32 битах не пойдет!

>> Вторая большая проблема с программами, считающими, что int = long.

>Ну это ваще! Этому же учат на первом курсе любого технического вуза!

Это может быть просто ошибкой. Например, файл a.c: long a; файл b.c: external int a; проканает на 32 битах, но не сработает на 64.

> Как это -- "разница поинтеров". В смысле "p1-p2"? Тогда зачем её пихать в int? Не всосал...

Пример из Кернигана и Риччи, функция strlen: char *p = s; while(*p != '\0') p++; return(p-s);

Кстати, на 64 битах длина строки МОЖЕТ быть > 2^32/2-1. Функция strlen поэтому должна иметь тип size_t, а не int.

> А у меня sizeof(bool)=1.

Починили уже, оказывается.

To sS:

А разве ламповый процессор -- это плохо? Великоват, правда, малость... Ну да это -- не проблема. Страна у нас большая!

>>Самая большая проблема с программами, в которых ПРОПИСАНО, что в int 4
>>char'а или 32 бита. Например, int *p=calloc(1,4)

>Ну, это уж руки из попы просто надо программистам доставать... То есть >про sizeof(), по-моему, написано просто в любой мала-мальской книжке по >С.

ну и с каких программистов начнем, что не знают, что int бывает не 4
байта? примеров - куча и множество... mplayer, pam, vox, aspseek... все
этим страдали (и некоторые страдают до сих пор). По своему опыту работы
под Linux на Alpha могу подтвердить, что из _ОЧЕНЬ_ многих пакетов
приходится вручную ошибки выковыривать подобного рода. Задирает.

Про unaligned traps я уже не говорю.

>world-class performance to high-volume workstations
ну и че, это тоже что и дестоп? или это тоже массовый рынок? Потребление энергии у него таково, что в домашних и офисных компах он буде лет через 10. да и размер кристала впечатляет. Так что ~700 баков за эту надгробную электро плиту- явно демпинг.
Mimino

>он буде лет через 10

через 2 года.

To Die-Hard:

Понятно всё. Все описанные проблемы, связанные с переходом на 64-х разрядную архитектуру с 32-х разрядной, возникают именно из-за того, что некоторые программы (IMHO маленькая их часть) априори полагают, что выполняются на 32-х процессоре. А это -- просто тупость невыносимая. И закладываться на неё разработчикам аппаратуры, по-моему, мягко говоря не стоит.

Ну через 2 будет разве что Итаниум-целерон кастрированный по самые немогу. А вообще посмотри на ТТХ и подумай Mimino

phicus (*) (2003-09-04 19:39:18.386517):

> Все описанные проблемы, ... возникают именно из-за того, что некоторые программы ... полагают, что выполняются на 32-х процессоре.

Не совсем.

Большинство проблем возникает из-за ОШИБОК, не проявлявшихся на 32 битах, которые полезли при переходе к 64.

32 бита - самая "комфортная" для программера платформа: разница между указателями - int; int=long; int в точности влазит в регистр; выравниваниями пренебрегают.

И на 16, и на 64 битах это все не так, и ошибки повылазят.

..... И наступает лучшее для программиста состояние -- состояние блаженного идиотизма ;) .......

>выравниваниями пренебрегают

ими пренедбегают не потому что на 32 битах оно не имеет значения а потоиу что на интелах выравнивание не требуется. На других 32 битных платформах оно часто необходимо.
Мимино

Opteron стоит 250$ так что зря интел своими 700$ демпингует....

а ведь его итаниумы 10000$ стоили...

народ, а какая разница в скорости для цикла for на 32-х битной и 64-х битной системах?

>Opteron стоит 250$ так что зря интел своими 700$ демпингует....

Ой ли: http://www.fcenter.ru/hardnews.shtml#ATH64PRICE

Mimino

>>Opteron стоит 250$ так что зря интел своими 700$ демпингует....

>Ой ли: http://www.fcenter.ru/hardnews.shtml#ATH64PRICE

Человек видимо имел ввиду фунты ;)

http://www.theinquirer.net/?article=11377AMD?s marketing dept. has a problem to solve until September 23, and that is how to price their new mainstream product, the Athlon64. Price basically positions a product against its competition, so it?s useful that Intel has already announced its P4 prices for 26 October. Here is a table comparing the prices of some CPUs and a possible price range for the Athlon64 models:

P4 now P4 26/10 AthlonXP now Opteron 1XX Athlon64 min Athlon64 max

3.2GHz $670 $420 --- 1.8GHz $669 2.0GHz $420 $580

3.0GHz $366 $275 2.2GHz $440 1.6GHz $438 1.8GHz $300 $400

2.8GHz $247 $220 2.16GHz $275 1.4GHz $229 1.6GHz $190 $280

All these CPUs are built on 130nm processes, but Intel has a clear advantage: it uses 300mm wafers vs. 200mm for AMD. And Intel has preemptively announced that it is ready to use pricing to keep its market share intact.

AMD has a single tier one manufacturer announced at this point: HP. It?s quite possible that a large % of Athlon64 will initially find their way to the DIY or white box markets. AMD has to be careful that the Athlon64 does not canibalize its own AthlonXP sales, but the loss from this would be minimal: AMD?s top AthlonXP speed grades are sold in minute quantities - and that?s where the Athlon64 comes in.

Right now it seems AMD is going to win some market share back from Intel. But Intel still has 2 - 3 months to find a strategy to neutralize AMD?s Athlon64 launch. More advertising won?t help at this point, Intel has to find something to make its products more attractive.

все это гон, глядите: http://www.stolica.ru/cgi/php/parts.php?r=77&g=CPU&w=opteron&ord=...

А мне честно говоря по БАРАБАНУ какой проц в машине:-) Главное чтобы работало Софт надо писать а не на форумах трепаться (поле то непаханное)

>Одна - в Москве. На всю остальную 1/6 часть суши планеты Земля
>приходится ещё одна такая машина.

У меня под рукой (в Москве) уже сейчас есть два сервера 2x на itanium2. На днях будет еще два. Не надо путать количество проданных экземпляров с общим количеством.

Вот я сейчас подбираю новый сервер под базу. Была мысль что мол 64 бита это рулез немеренный для базы. Посмотрел цену: Itanium - самый дорогой и в бюджет не вписывается. Неудивительно что его никто не покупает.

То что можно серверок от IBM на Power4+ взять за гораздо меньшие деньги это факт, а он еще фору итаниуму на 100 очков вперед даст. Правда все равно слишком дорого.

Opteron вполне приемлимо по цене - но под него нет пока дебиана, значит нам такого не надо.

Вот так и придется жить по старому - гонять 32 бита на xeonах. :(

процессор без софта - сапожник сосущий офигенного размера кеглю :-))))

>>Принципиально неустранимая проблема: на 64 битах разница поинтеров >>может не поместиться в int.
Бредить то не надо: разница указателей типа size_t

>>Проблема, специфическая для g++: на 32 битах bool=int (грубо говоря), >>а на 64 битах sizeof(bool)=8 (!)
Опять прогон:
$ gcc -v
Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs
gcc version 2.95.4 20011002 (Debian prerelease)

#include <cstdio>
int main()
{
printf ("%u\n", sizeof(bool));
return 0;
}

1
естественно sizeof(bool) в ANSI C/ANSI C++ равно 1...

Читал и плакал...

1. Для разницы указателей есть специальный тип: ptrdiff. Который и нужно использовать, не пытаясь приводить к int или long.
2. "#define int long", и на 64-битной никаких проблем с sizeof(int)==sizeof(long) и всем остальным не будет. Конечно это хак, но работает.

Так что единственная действительно реальная проблема -- это предположение, что sizeof(int)==4 (а sizeof(long)==4 или 8, sizeof(bool)==1 или 4 и т.п.).
Кстати, ни стандарт C, ни стандарт C++ ничего не говорят о том, сколько байт содержится в том или другом типе.

2ROOT: А ты знаешь что существуют вещи типа пакардовского тестдрайва?

У меня система с Itanium. Установил на ней RH 7.2 ( это то что лутьшее нашол бесплатно) Превое впечатление, сильно похож на своих родственников от Intel и трудно наити достойное ПО.

По поводу Bool=8 такоеже как и для OSF и других клонов с 64Б. gcc сделано одинаково для всех архитектур с 64Б( возможно с байтами опирировать легше чем выделять конкретный бит. Этиданные мы ведь не храним, мы постоянно сними должны работать, и когда Bool = 1 то я себе слабо представляю как можно оптимизировать код.)

>То что можно серверок от IBM на Power4+ взять за гораздо меньшие деньги это факт, а он еще фору итаниуму на 100 очков вперед даст. Правда все равно слишком дорого.

Ну насчет POWER4 тож кстати не очень понятно. Дорогая архитектура (mainframe-centric). Те тесты, которые так IBM выпячивает, в основном под одним процом в MMC, который и юзает весь L3-кэш. Да и не масштабируется он, по некоторым данным >40 на систему. С AIX-ом опять же вопросы, будет жить или нет. А линукс на pSeries пока отсасывает основательно.

Санки надо брать в общем, пока бардак такой, либо 32битный интель.

~finist

Мне жутко интересно:

Дрочат ли зомби и зачем?

И если ROOT весь на кластерах, зачем ему винда?

Если кому интересно про Альфу:

DEC выпускала Альфы. Году в 1999 ее купила Compaq. Потом Compaq объединился с HP. По слухам разработки и некоторые патенты на процессоры Alpha купила Intel.

Года два назад читал я очень умный журнал. Сравнивали процессоры RISC и CISC. Автор очень подробно рассмотрел все индивидуальные особенности процессоров и намекнул на то, что новейшие процессоры от Intel все более похожи на процессоры RISC. Похожи не буквально, но многие технологические решения RISC были применены в P-Pro, Xeon, Itanium.

Процессоры Альфа были весьма неплохими. В 90-х годах им не было равных в производительности и надежности. Многие крупные конторы их использовали. Некоторые используют до сих пор.

Одни говорят платформу Альфа убили неправильным маркетингом, другие говорят о технологическом тупике, третьи и непомерной стоимости разработки и изготовления, а как следствие - высокой стоимости конечного продукта. Наверно все по своему правы. Сейчас разработки по процессору Alpha закрыты. Разработчики влились в команду разработчиков Itanium.

Альфа оставила довольно яркий след в истории процессоростроения. В общем вечная память. Аминь.

Некоторые тут про Самсунг вспомнили. Да, действительно, процы Альфа и некоторые компоненты делали на заводах Samsung Semiconductor.

HP до сих пор самостоятельно поддерждивает RedHat 7.2 для процессоров Alpha. Радует то, что такая уважаемая фирма не кинула старую умирающую платформу в одночасье, как это сделали многие.

Такие вот дела.

ответ

">Opteron стоит 250$ так что зря интел своими 700$ демпингует....

Ой ли: http://www.fcenter.ru/hardnews.shtml#ATH64PRICE

Mimino"

как же много на свете пи***болов. Простите меня... Лень пойти и посмотреть на официальную инфу? Вот ссылка по русски для простоты: Оптерон 240 уже сейчас стоит 250$. А Атлон64 по определению должен стоить дешевле, ибо он расчитан на однопроцессорность, и работает с обычной памятью, и вобще рассчитан для массового пользователя. Топы конечно подороже... но все равно не больше 600$ за !серверный! проц.

http://www.ixbt.com/news/index.php?news_id=93908&str=%F6%E5%ED%FB+%26+amd...

кстати. А сколько стоит итаниум в сборке? Плата материнская под Атлон64 стоит не сильно дороже платы под АтлонХП и их уже дофига наобьявляли.

А сколько стоит оно под Итаниум 1, 2? И бывает ли на итаниумах AGP? Можно ли на итаниуме погамать в Дуум3?:)

Эээ... чё-то я не понял про дороговизну Alpha в производстве...
Там вроде как раз прикол был в том, что такая производительность была без навороченных многослойных кристаллов и с невысокой плотностью...

>У меня под рукой (в Москве) уже сейчас есть два сервера 2x на itanium2. На днях будет еще два. Не надо путать количество проданных экземпляров с общим количеством.

О, ты уже научился незаконно копировать процессоры?

Поделись кряком!

Shadow: А какая уже разница? Нету Альфы. Вечная память...

>Поделись кряком!
Легко. Берешь или создаешь хороший софт под итаниум. Идешь в представительство интела и просишь "на попробовать" нужное количество.
И получаешь искомое...

2anonymous (*) (2003-09-05 13:36:39.048951)
мы так от IBM сервер с AIX получили, надо и с интелом попробовать :).

anonymous (*) (2003-09-05 00:18:59.341876):

> То что можно серверок от IBM на Power4+ взять за гораздо меньшие деньги это факт,

Откуда такая инфа?

Мы полгода ведем переговоры на тему Итаниумов/Оптеронов/ИБМ - цены от ИБМ примерно в 5 раз выше Итаниумных за сравнимые решения (университет в Германии), а Оптероном в обозримом будущем не пахнет вообще.

Да, нас интересуют серваки от 8 голов и выше.

anonymous (*) (2003-09-05 01:14:51.379113):

> Бредить то не надо: разница указателей типа size_t

Такое впечатление, что анонимусы просто прутся от того, что пишут сюда крутые фразы.

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

anonymous (*) (2003-09-05 02:54:43.010326):

> Для разницы указателей есть специальный тип: ptrdiff.

Молодец!

Я могу только повториться: в 32-битных системах разница поинтеров всегда int. Про это говорили создатели языка, этим люди широко пользовались, и это не считалось ошибкой.

При переходе 32->64 это может породить проблемы.

С чем ты не согласен?

Кстати, под ДОСом в распространенной large модели вычитание поинтеров вообще приводило к бредовым результатам.

The GNU C Library, Reference Manual:

Compatibility Note: Pre-ANSI C implementations generally used unsigned int for representing object sizes and int for pointer subtraction results. They did not necessarily define either size_t or ptrdiff_t. Unix systems did define size_t, in `sys/types.h', but the definition was usually a signed type.

> "#define int long" ... Конечно это хак, но работает.

Ну да? За такие хаки нужно руки отрывать.

В след. посте примерчик кину, чтобы форматирование не сбивать.

Файл tst.c:

#include <stdio.h>
#define int long


int main(void)
{
int a=-1;
long b=0;
   scanf("%d",&a);
   b=a;
   printf("Res:%ld\n",b);
   return 0;
}

$gcc -pedantic-errors -o tst tst.c
tst.c: In function `main':
tst.c:6: return type of `main' is not `int'

Ok, 
$gcc -o tst tst.c
tst.c: In function `main':
tst.c:6: warning:  return type of `main' is not `int'

$uname -s -m
Linux i686
$/.tst
1
Res:1

$uname -s -m
OSF1 alpha
$/.tst
1
Res:-4294967295

Ни хрена себе, переносимость!
Подобные хаки называются 
"систематическое введение компилера в заблуждение."

Что будет действительно сложно перенести, так это проги типа
Wine, dosemu и прочие эмуляторы. Вот тут-то возникнут проблемы
по-фундаментальнее. А все ваши размеры интов - это просто смешно.
Это фиксится за 2 минуты и нормальные разработчики позаботятся
об этом заранее.
А вот когда прога получает SIGSEGV сотни раз в секунду и в
обработчике сигнала правит регистры в сохранённом контексте
(dosemu) - вот это действительно вызовет проблемы. И таких
примеров полно. Те, кто считает, что размер типов - основная
проблема переносимости, скорее всего кроме "Hello World" мало
какие проги сами писали.

>Что будет действительно сложно перенести, так это проги типа
>Wine, dosemu и прочие эмуляторы. Вот тут-то возникнут проблемы
>по-фундаментальнее. А все ваши размеры интов - это просто смешно.
>Это фиксится за 2 минуты и нормальные разработчики позаботятся
>об этом заранее.
>А вот когда прога получает SIGSEGV сотни раз в секунду и в
>обработчике сигнала правит регистры в сохранённом контексте
>(dosemu) - вот это действительно вызовет проблемы. И таких
>примеров полно. Те, кто считает, что размер типов - основная
>проблема переносимости, скорее всего кроме "Hello World" мало
>какие проги сами писали.


Это задача вообще из другой оперы
Это считай то же что пытаться перенести dosemu на SPARC

За использование scanf - руки надо отрывать однозначно.

"Помню, как в 1994 году пытались пнуть фирму "Интел", допустившую глюк в Pentium. Смеху было! Ну и кто сейчай самый массовый процессор? То же и с Itanium."

Что значит "пнуть"? Народ откровенно возмутился политикой фирмы, которая продала им брак и отказалась менять. Потом была такая формулировка "Мы заменим это Вам, но только если Вы объясните, зачем это Вам надо", после чего пошли шутки, что в Intel выдают зарплату, но только если сотрудник объяснит, зачем она ему нужна... Вой в СМИ нарастал, и в итоге они согласились на обмен всем желающим. А пинать intel с рынка никто и не собирался.