Попробовать конечно можно что за зверь в качестве второго компайлера.
Быстрее не важно важно чтоб качественно делал.

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

Дык ничего удивительного. Я тут устал уже фанатам GCC указывать на тот факт, что на КАЖДОЙ поддерживаемой им платформе он отстаёт от родного для этой платформы компилятора. Просто на x86 это не так заметно было, но вот на Альфах, Спарках, Мипсах, PA-RISC, Power - просто бяда. Это - цена портабельности.

только вот интересно почему сделано только под RedHat?
в интеле думают что линух это только шапка?

А при чем тут Шапка? Там все тестирование на Сузе делалось.

Незнаю причем тут шапка но компайлер запакован в rpm и написано что он для RedHat 6.1 и для RedHat 7.1.

Просто в Интеле знают, что редхотовцы - люди несчастные, им только rpm подавай.. А остальные и из rpm все что надо вытащат :-)))))

Зато, кстати, интелевый компайлер гораздо хуже совместим со стандартом, чем gcc, или, скажем, kai. Вообще, интелевые компайлеры и политика интел в этой области мне совсем не нравится -- сначала купили kai, в результате лучшего в природе компилятора под винды не существует, теперь со своей лажей (к тому же, насколько я понял, платной) лезут на линукс, где kai опять-таки уже есть. Странная политика -- отбивать рынок и бабки у своего же подразделения...

Ну на счет скорости виндовс vs Линукс - дело каждого (компилятора разумеется :-), но к примеру XML-XSLT парсер от команды Apache.
Один и тот же код компилированный под линук и виндовс. Под линукс работает на 370% быстрее. Делайте выводы. В парсере нет графики и т.д., по сути только вычисления и в Линукс они быстрее.

Хотя, возможно, что я не прав. Убедите в обратном.

А чем этот парсер на винде компилили? Не gnu случаем? Тем более в этой статье еще рассказывается, что новый компилятор от MS по скорости такой же как интеловский на линуксе.

Кто пробовал??? Как качество??? Как скорость на атлоне К7 ??????? етц.

Статья очень похожа на рекламу. Нигде не описано что такое "OBLcpu benchmark". С помощью google не удалось найти информации по тесту. Неизвестно также, с какими оптимизационными опциями все компилировалось. Так что остается только верить (или не верить) авторам на слово.

Хотя, наверное, g++ имеет некоторые проблемы. Кроме того, gcc-2.95 может оптимизировать только под pentium pro или k6 - довольно старые процессоры.

To Antichrist:

Ссылочки, пожалуйста или циферки. А так только общие слова. К примеру Сан тоже года полтора-два назад кричал, что с его Forte C или как он тогда назывался, проги будут работать чуть ли не на 50% быстрее, чем после GCC. Так потом помню проводили исследование - выяснилось, что преимущество лишь в некоторых тестах на 5-7%. А за сановский компайлер нужно отвалить один-два килобакса.

я думаю что это рекламмный трюк. People я за то что бы во всем была свобода выбора , если кто то хочет платить деньги за Intel C++ компиллер то пускай платит , а есл иу кого то нет такой возможности или не хочет пускай юзает gcc.

Господа! А нужен ли нам "самый быстрый" компилятор?
Согласен, никто бы не возражал повышению производительности
"бесплатно", но
-- он (intel С++) не бесплатен
-- кроме cpu intel есть cpu athlon, который в ряде случаев лучше/дешевле
-- ошибки gcc(g++) известны проффесионалам и те их обходят; что бы
найти ошибки в новом компиляторе нужно время, люди и упорный труд,
а это как правило не оплачивается. По CMM, новое средство разработки
всегда риск, т.е. снижение качества проекта.
-- gcc доползет до этого уровня производительности и качества кода
за пару лет, а вот хватит у intel _постоянно_ совершенствовать свой
компилятор, я сомневаюсь.

2 Antichrist (*) (2002-01-27 22:24:17.0)
Ты бы что-нибудь нетревиальное доказывал. Написать непереносимую
фенечку под single ось и single cpu, намного проще, чем с поддержкой
оптимизации по выбору и переносимо.

2 anonymous (*) (2002-01-27 22:52:50.0)
Для корпоративного использования есть только два линуха: RH и SuSe.
И не потому что они лучше-хуже slakware/debian/etc. Просто у них
есть нормальная платная поддержка (которая часто нафиг не нужна, а
еще чаще не эффективна). Разработчики ядра где кормятся и что сами
рекомендуют?

Статья меня разозлила, и я даж вытягиваю сейчас этот интеловский компилер. Не верю я тому что там написано, попробую сам. О результатах собщу тут. Вобще, как мне кажется это действительно реклама, например подозрителен тот факт что в тестах код генерируемый icc@winxp быстрее чем код icc@linux, => winxp как ОС быстрее linux'а (icc генерирует идентичный код на обоих платформах, как написано в статье). Кто-нибудь верит в это?

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

> А чем этот парсер на винде компилили? Не gnu случаем? Тем более в этой
> статье еще рассказывается, что новый компилятор от MS по скорости
> такой же как интеловский на линуксе.
XML-XSLT парсер компилирован был MSVC++ 7.0 (кажется версией не ошибся).

Так что притензий нет. На каждой платформе был свой "родной" компилятор.

2 alexros Самое интересное, что правда это про SUN'овский компилятор и GCC. Потерял результаты тестов к сожалению....

Господа, а кто-нибудь обратил внимание на цифры? НЕ МОЖЕТ компилятор делать прогу быстрее на 47%! Gcc не настолько плох, чтобы так вот в полтора раза только из-за компилятора скорость выполнения кода возрасла. Вилки есть -- лапшу с ушей снимать? ;) То же самое и к сановскому заявлению относится.

Да, gcc не многих платформах делает не настолько хороший код как "родной" компилятор для этой платформы. Не потому, что gcc -- portable, а скорее по другим причинам, например, доступности документации, совместимости с болеее ранними процессорами (а может ли icc для чистого i386 код генерить?), в недостатке сил, наконец (частично по причине portability -- много платформ поддерживать не так-то просто) и т.д. В самом gcc проблем с его portability и его влиянием на качестве оптимизации, в общем-то, не имеется.

Кто-нибудь смотрел то, что выдаёт gcc? В ассемблере? Вполне себе код, да, навороченный несколько, да, есть лишнее, да, можно во многих местах улучшить (наверное). Но не в полтора раза -- если только в icc использованы совсем другие инструкци, о которых только самому интелу известно и которые работают в эти самые полтора раза быстрее.

На 5-10% быстрее -- можно. Не не в полтора раза.

Ещё момент. Ерундистика насчёт скорости под вынь/линукс. Если компилятор один, то и код он генерит один (если, конечно, под вынью не компилили с оптимизацией, а под линукс - без, например). То есть собственно *код* будет так же работать под *любой* OS на этом же железе. Однако есть ещё системные функции (ввод/вывод например), которые и реализованы, и вызываются по-разному, и куча всяких других особенностей. Тот же I/O: open/read/close в винде эмулируются через OpenFile/.../CloseHandle. Можно сделать наоборот, написать прогу под винду и сэмулировать эти OpenFile/... через POSIX'овые open/.., причём сэмулировать плохо, а потом говорить, что *компилятор* генерит лучший код для винды чем для линукса. Тут есть правда ещё момент интересный -- *в принципе*, возможна игра с конвейерами, с кешем и проч. на основе того, что известно, как именно работает операционка, и как-то в этом куске пытаться оптимизировать. В принципе -- я не уверен, что это можно практически применить. Но при этом можно будет сказать, что этот *компилятор* генерит более быстрый код для такой-то операционки.

Да, и новость названа некорректно. Не компилятор быстрее или медленнее, а код, им генерируемый! :)

2 Rabbit:>Господа! А нужен ли нам "самый быстрый" компилятор?
Нужен. Этот компилятор дает реальный прирост скорости по отношению к gcc. Есть проекты, где скорость критична. За счет хорошо оптимизирующего компилятора и возможности заточить под него код можно изрядно выиграть.

>-- он (intel С++) не бесплатен
Во-первых, он не так дорог. Во-вторых, а в чем проблема? Компилятор же не домой покупают. Хотя, конечно, есть случаи, где скорость не нужна, и gcc хватает.

>-- кроме cpu intel есть cpu athlon, который в ряде случаев лучше/дешевле
Такие компиляторы оптимизируют не только "внизу". Intel и kai выполняют и оптимизацию, так сказать, на уровне исходного кода и его представления.

>- ошибки gcc(g++) известны проффесионалам и те их обходят;
Ошибки Intel тоже известны профессионалам. Это не такой новый компилятор, как кажется.

>-- gcc доползет до этого уровня производительности и качества кода
за пару лет
Не факт. Кроме того, мы живем сейчас, а не через пару лет.
>а вот хватит у intel _постоянно_ совершенствовать свой компилятор, я сомневаюсь.
Нет, ну странная у вас логика. Почему это gcc должен развиваться, а intel нет? Нынешнее состояние intel -- это же не предел совершенства.
Есть те же kai и portland, которые пока превосходят intel даже на его родной платформе -- так что есть к чем стремиться.

>Написать непереносимую фенечку под single ось и single cpu, намного проще, чем с поддержкой оптимизации по выбору и переносимо.
Опять же, посмотрите на тот же kai -- он существует почти под все юниксы, и везде превосходит "родные" компиляторы. Так что и переносимо с поддержкой оптимизации по выбору писать можно, и лучше, чем это получается у gcc team. Это я к тому, что в плане оптимизации/кодогенерации gcc -- просто-напросто хреновый компилятор. Коммерческие компиляторы в этом аспекте лучше, и очевидно почему.

Пиплы, я с годик назад смотрел этот компилятор (виндовый, правда).
В нем вся фишка - это заточенность под MMX/SSE.
И таки да, перемножение матриц 4x4 в нем делается парой команд и быстрее, чем в лоб обычным способом. Он хорош для компиляции модулей с интенсивной математикой, с ним идет оптимизированная библиотечка для работы с векторами и матрицами (для графики в самый раз). Но оптимизировалась она руками.
Для обычных задач разницы особой не будет.

Испугал ежа задницей

Конечно, быстрее! А под Линухом -- KAI быстрее, чем gcc и чем Intel под виндой. И что?

gcc -- средство для того, чтоб софтина, где нужна портабельность, встала везде и сразу. А чтоб считать -- нужны другие инструменты.

Никто ведь не пытается писать ядро ОС на перле? Хотя...

2 mjt:>господа, а кто-нибудь обратил внимание на цифры? НЕ МОЖЕТ компилятор делать прогу быстрее на 47%! Gcc не настолько плох, чтобы так вот в полтора раза только из-за компилятора скорость выполнения кода возрасла.
МОЖЕТ. Если бы я сам этого не видел каждый день на наших проектах, я бы не говорил. Во многих случаях тот же kai генерирует код в _два_ раза меньше по объему, и в среднем на 30-40 процентов быстрее. Intel процентов на 20-30. GCC, например, очень плохо справляется с навороченным template-based кодом, который "заточен" на возможности компилятора по оптимизации -- типа blitz или mtl.

>Кто-нибудь смотрел то, что выдаёт gcc? В ассемблере?
Это смотря что ему дать:)

>Но не в полтора раза -- если только в icc использованы совсем другие инструкци, о которых только самому интелу известно и которые работают в эти самые полтора раза быстрее.
Оптимизировать можно не только "машинный" код. Пример -- kai, который вообще, грубо говоря, делает C-код и затем пользуется на каждой платформе родным C-компилятором.

>На 5-10% быстрее -- можно. Не не в полтора раза.
Можно и именно в полтора раза.

По поводу скорости под вынь/линукс. У интелевого компилятора своя rtl, которую нужно линковать с каждой программой. Под вынь rtl может быть реализована лучше.

>не компилятор быстрее или медленнее, а код, им генерируемый! :)
Кстати, компилятор тоже быстрее:)

About 47 % - BULLSHIT.
Have already tried this compiler (we really needed some extra speed),
and it turned out it is some 4 - 7 % faster (not 47 :))) ) depending on the code. 

англоязычному анонимусу: зависит от кода и от того, как писать. Во многих случаях, интел действительно не намного быстрее gcc. И intel, и kai намного быстрее на коде, интенсивно используеющем шаблоны. И, кстати, если вам действительно нужно some extra speed, попробуйте kai или portland.

2 AC (*) (2002-01-28 13:09:30.0)
Согласен, но ключевые слова "Нужен", "Есть проекты", "Скорость критична" и т.п. в направлении повышения требований. Да, для особого
случая всегда купим что-то остро-заточенное.

Но, с другой стороны, что из GNU-софта, реально требует высокой
оптимизации (я за пять минут не придумал)? Больше ценится
предсказуемость и обратная совместимость -- сколько идет флема по
поводу gcc 3.*! Для комерческих проектов купят и за пять штук и за
десять. Но, чистка кода, продуманный алгоритм, отказ от удобных
средств вроде ++, и, наконец, пара-тройка сотен строк на nasm будет
на порядок эффективнее любого заточенного компилятора эффективнее.

А gcc/g++ остается независимой переносимой платформой, достаточно
эффективной для разрабоки прототипа.

Присоединюсь к Havoc. Во-первых Огр, как известно, не умеющий читать по английски (и писать по русски) неправильно анонсировал новость. В оригинале написано: "...Intel... smoke GNU C and MS Visual C++ in number crunching benchmarks". Что в переводе (Огр, ау!) означает в "числодробительных тестах".

Новость, на самом деле про то, что Интел написал компилятор, который на автомате использует SSE, а gcc еще их не использует. Вот и все. Удивительно что обогнал всего на 47%. Использование SIMD должно давать выигрыш в 2-4 раза на задачах интенсивных вычислений. Так что Интелу еще работать и работать.

Разница между Линуксом и Виндовзом заключается в том, что хотя код одинаковый, затачивают компилятор в первую очередь под Виндовз. Кстати, в VC есть куски кода интеловского компилятора.

Как gcc начнет использовать SSE, так разница сразу испарится. Для обычных задач это, вообще, не имеет значения.

2 BlackRabbit: Не согласен.
>Но, с другой стороны, что из GNU-софта, реально требует высокой
оптимизации (я за пять минут не придумал)?
А почему именно GNU-софта? Что, другого софта не существует?
>Больше ценится предсказуемость и обратная совместимость
Кто сказал, что коммерческие компиляторы предсказуемы, и не совместимы?
>для комерческих проектов купят и за пять штук и за десять.
Эти компиляторы не настолько дороги.
>Но, чистка кода, продуманный алгоритм, отказ от удобных
средств вроде ++, и, наконец, пара-тройка сотен строк на nasm
По-поводу алгоритма -- согласен. Считаем, что выбран оптимальный. Но, во-первых, хорошо оптимизирующие компиляторы как раз и требуют специальной организации кода -- это по поводу чистки. Во-вторых, за счет "удобных средств ++" можно получить выигрыш даже по отношению к чистому C, не говоря уже о удобстве и лучшей структурированности. В-третьих, писать на asm для скорости вообще последнее дело. Единственный разумный пример его применения -- gmp.
>будет на порядок эффективнее любого заточенного компилятора
Это не так.

2 AC (*) (2002-01-28 14:12:15.0)
>А почему именно GNU-софта? Что, другого софта не существует?
Ну, я взял на себя смелость, сделать такое предположение, в контексте
тематики сайта.
>Больше ценится предсказуемость и обратная совместимость
Для солярки я использую SUN workshop, для win32 - vc 6.0. В двух
проектах использовали интелевский (не помню версии) -- конфигурация
среды растет от заказчика.
По опыту, если не пишешь GUI, то можно писать очень переносимо.
Дюжина #ifdef ... #endif на заголовки и wrapper'ы на большинство syscall'ов. А бизнес логика обычно ничего такого не требует.

>>будет на порядок эффективнее любого заточенного компилятора
>Это не так.
Ну, я nasm/tasm/masm балуюсь (комерческое применение в прошлом), но
недавний проект потребовал оптимизации одного критичного метода.
Общий выигрыш был около 8-9 раз. В самом критическом методе в 14-18
раз. Понятно, что это частный случай, но тем не менее затраты
окупились. Код писал специалист-фанатик-оптимизации.

Блин ещё бы
смотрел я на код сгенерированый gcc (с оптимизацией)
куча лишних операций; всё время увеличивается/уменьшается esp когда можно сделать это 1 раз, и прочий маразм.
intel компилятор не пробовал

>Господа! А нужен ли нам "самый быстрый" компилятор? >Согласен, никто бы не возражал повышению производительности >"бесплатно", но >-- он (intel С++) не бесплатен Не совсем так... Intel раздает бесплатный компилер но без поддержки http://developer.intel.com/software/products/compilers/c50/linux/noncom.htm >-- кроме cpu intel есть cpu athlon, который в ряде случаев лучше/дешевле

Ну дык AMD тоже раздает инструмент правда как мне помнится только для VC++ (хотя давно у них не был ножет чего и изменилось )

>-- gcc доползет до этого уровня производительности и качества кода >за пару лет, а вот хватит у intel _постоянно_ совершенствовать свой >компилятор, я сомневаюсь.

Так и будет - как я понял из статьи про тесты и описание сего поделия от интель - в данный компилер включена нормальная поддержка SSE/SSE2 то есть включение его в GCC это вопрос времени (видимо и приведенные тесты были специально заточены под эти расширения - НО далеко не всякая задача гладко ложится на SIMD модель вычислений, так что в 95% случаев ImHO сие поделие от интеля не более не будет иметь 30% преимущества в производительности)

/SS

Ну типа отучаем его от вредной привычки работать только 30 дней и при этом еще грузить FlexLM v5.01 (проверено все только на коротких пакетах for Linux IA 32- длинные мне качать ломы):

C/C++: icc (size 483084): icpc (size 483112): offset e443, правим c7 04 24 48 46 на e9 12 02 00 00

И никогда не вызываем icid

Fortran: ifc (size 497293) offset ece3, правим с7 04 24 40 60 на e9 12 02 00 00

Эти т.н. "developerы" даже symbol info не стрипнули - так что работы на 10 минут.

PS: кто-нть пробовал скомпилить ЭТИМ binutils ? Что-то сыпется падла на struct stat в libiberty/getpwd.c. Может руки ?

Старый пионэр

> что в 95% случаев ImHO сие поделие от интеля не более не будет иметь 30% преимущества в производительности Кхм, пересобрал я свою задачку - поиск максимального пути в графе на C++. Имею сказать, что размером стало в три (3!) раза меньше и считает на ~40% быстрее на одних и тех же данных (юзал time для замера). Ни в icc и ни в gcc никаких доп. ключей не использовалось. Поскольку задача чисто расчетная и никаких интенсивных операций с диском не производится - вобщем делайте выводы сами

Старый пионэр

gcc с -O2 генерирует код в 2-4-ре раза быстрее чем без -O2.

Так што компилятор с оптимизацией может спокойно генерить код в 1.5-ра раза быстрее

>Кхм, пересобрал я свою >задачку - поиск максимального пути в графе на C++. Имею сказать, что размером стало в три (3!) раза меньше и считает на ~40% быстрее на одних >и тех же данных (юзал time для замера). Ни в icc и ни в gcc никаких доп. ключей не использовалось. Поскольку задача чисто расчетная и никаких

Могет дело вот в этом ------------------>"""""""""&quo t;""""""""""""" """""""""""""&q uot;""""""""""""&quo t;"""""""" ???

а если сделать gcc с -O2...9 ???

>интенсивных операций с диском не производится

А как ключи будут влиять на работу с диском ??? *8)

> - вобщем делайте выводы сами

Ща выкачаем и бум пробовать ...

/SS

Пересобрал с -O9 результаты поражают всякое мыслимое воображение по скорости gcc сосет на 15% по размеру - в 3.6 раза (! не увидел бы собственными глазами - ни за што б не поверил !) Нда... Для чистоты ксперимента щас заюзаю еще оптимизацию icc

Старый пионэр

icc -ip -tpp6 -O3 -axiM сделал gcc -O9
по размеру - в 3 раза
по скорости - на те же 40%
Пошел перекомпилять весь проект на icc

Старый пионэр

2 anonymous (*) (2002-01-28 16:28:22.0) "а если сделать gcc с -O2...9 ??? " - O2 - хорошо. Но можно лучьше. Об этом ниже. Но на >=О3 gcc (не знаю, все версии или только мою) начинает колбасить так, что неоптимизированный код работает быстрее. Самый оптимальный набор ключей для генерации быстрого кода ИМХО : -O2 -Wall -Wno-unused -funroll-loops -fstrength-reduce -fomit-frame-pointer -ffast-math -malign-functions=2 -malign-jumps=2 -malign-loops=2

A zachem lomat' fortran, esli on i tak free for non-commercial usage? Ili nuzhen support? :)

>icc -ip -tpp6 -O3 -axiM сделал gcc -O9 >по размеру - в 3 раза >по скорости - на те же 40% >Пошел перекомпилять весь проект на icc

1) Камень какой ? 2) Проект на C или на C++ ?

/SS

Камень P-III
C++

Fortran сломал шоб lmgrd зря не грузило

Давно говорил: Intel компИлер C/C++ быстрее чем GCC

Юзаю Интел-компИлер ьольше года (ещё с бетт), код действительно он генерил более быстрый (насчёт времени компиляции никогда не задумывался - поставил, ушёл на работу или лёг спать :)). Правда, ощутимый (и очень) форсаж был до 3-го ГКК, даже код ГКК 2.95.3 с объектпрелинком не давала такую выигрышность. Про "почти на половину" не скажу, а вот процентов на "до30" - реально. Недостатки следующие:
1) Падучесть приложений при совместном использовании ГКК и интела. Дефект до конца не исследовал (а может и кривые руки) - но, допустим, ядро и Цлибы - ГКК-шные, а всё остальное - от интёла... И периодами хоть комп на помойку неси...
2) Некоторые проги не компилятся с интёлом (ГКК в этом случае всеяден, или чтоли лоялен) - достаточно было правок руками... Да и вообще - многие злоупотребляют расширениями ГКК...
3) Некоторые спецфичные весчИ либо не компилятся вовсе, либо заведомо не имеют такого крутого форсажа (допустим, ядро...) - я извернулся только поставив Mach32 - но это уже не линух :):):D

А так, классические Си и Си с плюсиками - реализованы полностью... и без закрутасов..

Хотя, ИМХО, и можно поюзать, но лучше пинать своих (или не очень) иг команды ГКК, или расширять сферу оптимизаторов (всё равно, команда ГКК - не законченные идиоты, если дело действительно стоящее - втянут в компилятор)... Да и те кто на самом деле пишут для "кросс" с халявовложениями - наврядли захотят с ГКК слезать...

А для Мипсов нет даже коммерческих крутых компиляторов - всё фуфло...

2 asoneofus: Неправда. Под мипсы kai довольно рулит.

Кстати код (в целом) насколько плохо по скорости собирать с -O20 -march=pentiumpro для AMD K7?

Кстати старый пионэр пересобери код с -O20 -march=pentiumpro, потом набери strip (бинарник и сообщи разницу по размеру с icc, если не трудно).

и по скорости тоже юудет быстрее с march=pentiumpro

2) Некоторые проги не компилятся с интёлом (ГКК в этом случае всеяден, или чтоли лоялен) - достаточно было правок руками... Да и вообще - многие злоупотребляют расширениями ГКК...

То есть к примеру PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP обломится на нем ?

/SS

Ну вот: А как-бы кэй поиметь

Ну не знаю... Темноват я в этом деле - про кэй под мипсы MIPS-II ISA ничего не слышал, как и про оптимизацию в нём длинного конвеера конкретных реализаций... Кстати, кэй демы больше не выставляет?

2 AC (*) (2002-01-28 13:37:46.0):
yep, already using KAI...much better than Intel..
And, yes, exactly, it depends on the code, I just said that for our project the advantage of icc over gcc varied from 4 to 7 %.
So a question arises, why would anyone need Intel's compiler?
If we are working on some non-time-critical tasks, gcc is more than enough.
Now if we really need the optimizations, if we really want to cut all the curves there are, there is KAI.

2saper: та же хрень. Вот так строка для gcc выглядит в последней инкарнации:

-O20 -mpentiumpro -funroll-loops -fomit-frame-pointer -ffast-math -malign-jumps=2 -malign-loops=2

По размеру делает icc в те же 3 раза, по скорости - примерно на ~15% (мне лично скорость более интересна, бо задача практически переборная). А как безобразно в IDA Pro код от icc смотрится - это вообще словами описать нельзя. Что характерно - работает при этом правильно :-)

> кэй демы больше не выставляет
это куда ? и как внешне выглядит ?

Старый пионэр