Java vs. C++ (Отрезано от: ide с полноценным code complition)

[Olegator]

я запускал c 768 МБ ОЗУ и 1.9ГГц процессором - куда больше? Студия от Мелкомягких "ест" меньше, а умеет больше. по-моему просто IDE кривая.

просто на неподходящем языке написана, для таких проектов надо было использовать c++ а не java

[izen.fire]

я запускал c 768 МБ ОЗУ и 1.9ГГц процессором - куда больше? Студия от Мелкомягких "ест" меньше, а умеет больше. по-моему просто IDE кривая.

просто на неподходящем языке написана, для таких проектов надо было использовать c++ а не java

Откуда дровишки?
Eclipse использет нативные вызовы (через JNI) к системным библиотекам для отрисовки элементов управления, а всё остльное работает в Java. JNI тормозит на версиях Java младше 1.6.
Сам Java-байткод при переводе его в нэйтив оптимизируется JIT'ом на конкретной системе под конкретный процессор и объём памяти насколько это возможно. У Sun JVM есть опции использовать ту или иную стратегию сборки мусора и всяческой оптимизации. По умолчанию выставлен режим hotspot и опция -client, но он подходящь только для небольших приложений типа Azureus.

P.S.
Попытались бы написать NetBeans полностью на C++, посмотрел бы я на тормоза. Она бы всю дорогу думала. С++ заметно тормознее отJIT'енного байткода.

[innkeeper]

я запускал c 768 МБ ОЗУ и 1.9ГГц процессором - куда больше? Студия от Мелкомягких "ест" меньше, а умеет больше. по-моему просто IDE кривая.

просто на неподходящем языке написана, для таких проектов надо было использовать c++ а не java

Откуда дровишки?
Eclipse использет нативные вызовы (через JNI) к системным библиотекам для отрисовки элементов управления, а всё остльное работает в Java. JNI тормозит на версиях Java младше 1.6.
Сам Java-байткод при переводе его в нэйтив оптимизируется JIT'ом на конкретной системе под конкретный процессор и объём памяти насколько это возможно. У Sun JVM есть опции использовать ту или иную стратегию сборки мусора и всяческой оптимизации. По умолчанию выставлен режим hotspot и опция -client, но он подходящь только для небольших приложений типа Azureus.

P.S.
Попытались бы написать NetBeans полностью на C++, посмотрел бы я на тормоза. Она бы всю дорогу думала. С++ заметно тормознее отJIT'енного байткода.

А как "отJIT'енный" код может быть быстрее C++? Вся реализация java разве не через С++ идёт?

[izen.fire]

А как "отJIT'енный" код может быть быстрее C++? Вся реализация java разве не через С++ идёт?

Как вы представляете себе работу JIT? Термин "шитый код" применительно к результату работы JIT вам ни о чём не говорит?

Да JVM хоть на бейсике былы бы написана (утрирую, конечно), но отJIT'енный код будет выполняться с той же скоростью, что и машинный, так как он и есть машинный.

[/dev/random]

А как "отJIT'енный" код может быть быстрее C++? Вся реализация java разве не через С++ идёт?

Как вы представляете себе работу JIT? Термин "шитый код" применительно к результату работы JIT вам ни о чём не говорит?

Да JVM хоть на бейсике былы бы написана (утрирую, конечно), но отJIT'енный код будет выполняться с той же скоростью, что и машинный, так как он и есть машинный.

Машинный код машинному коду рознь. "На лету" провернуть полноценную оптимизацию гораздо сложнее, чем заранее, имея практически неограниченное время. Да и сама выполняемая "на лету" трансляция хоть немного времени, да съедает, создавая небольшие дополнительные тормоза. А если бы вставили нормальную оптимизацию - тормоза создавались бы _большие_.

И ещё один довод - JIT принципиально (неустранимо, исходя из самой концепции, а не реализации) конфликтует с такими средствами защиты, как PaX или ExecShield. А отключить их только для Java-программ, не затрагивая остальные, возможно, но бессмысленно - либо защищать всё, либо толку-то от такой защиты...

[izen.fire]

А когда вы откомпилируете программу С++, она будет не на машинном языке?

Ага. Статически слинкованный машкод, без учёта конкретной обстановки выполнения. Чаще всего под i686 (Pentium-Pro), без учёта длины конвейера процессора, размера кэш-памяти и различных оптимизаций для TLB.

JIT делает всё на лету, первый раз медленно, а потом очень быстро, так как байткод, с одной стороны, и конкретная информация о железе, с другой стороны, делают возможность проведения оптимальной трансляции байткода в машкод сразу после загрузки .class-файлов.
Class-файлы содержат больше информации, чем "шитый" код. JIT может оптимизировать вызовы методов (инлайнинг), а в современной версии JVM 6.0 временные объекты могут инстанцироваться не в куче, а на стэке, что повышает скорость доступа к ним и работу с ними в разы. Для программы на C++ пришлось бы писать такую оптимизацию вручную, с использованием сторонних библиотек.

И ещё один довод - JIT принципиально (неустранимо, исходя из самой концепции, а не реализации) конфликтует с такими средствами защиты, как PaX или ExecShield. А отключить их только для Java-программ, не затрагивая остальные, возможно, но бессмысленно - либо защищать всё, либо толку-то от такой защиты...

Откуда такая информация?
Во-первых, JIT начинает работу с кодом .class-файла после того, как байткод прошёл верификацию и получил определённые права доступа от SecurityManager.
Во-вторых, JIT более предсказуем по результирующему коду для байткода, чем какой-нибудь GCC для C++, так как спецификация байткода очень компактна (в отличие от C++).

[v04bvs]

Машинный код машинному коду рознь. "На лету" провернуть полноценную оптимизацию гораздо сложнее, чем заранее, имея практически неограниченное время.

Но и данных для оптимизации куда больше.

И ещё один довод - JIT принципиально (неустранимо, исходя из самой концепции, а не реализации) конфликтует с такими средствами защиты, как PaX или ExecShield. А отключить их только для Java-программ, не затрагивая остальные, возможно, но бессмысленно - либо защищать всё, либо толку-то от такой защиты...

Я правильно понимаю, что вы имеете в виду аппартный бит execute для участка памяти? Это тривиально, при выделении памяти нужно об этом сказать операционной системе о своих намерениях передавать управление на этот участок памяти, вот и всё.

[/dev/random]

Машинный код машинному коду рознь. "На лету" провернуть полноценную оптимизацию гораздо сложнее, чем заранее, имея практически неограниченное время.

Но и данных для оптимизации куда больше.

В бинарных дистрах - может быть. Но я-то gentoo юзаю, и на этапе компиляции уже известна каждая мелочь о компьютере.

И ещё один довод - JIT принципиально (неустранимо, исходя из самой концепции, а не реализации) конфликтует с такими средствами защиты, как PaX или ExecShield. А отключить их только для Java-программ, не затрагивая остальные, возможно, но бессмысленно - либо защищать всё, либо толку-то от такой защиты...

Я правильно понимаю, что вы имеете в виду аппартный бит execute для участка памяти? Это тривиально, при выделении памяти нужно об этом сказать операционной системе о своих намерениях передавать управление на этот участок памяти, вот и всё.

The last feature of NOEXEC is the locking down of permissions on memory
pages. This means that we prevent the creation of writable/executable file
mappings (anonymous mappings are already made non-executable) and we also
refuse to turn a writable or non-executable mapping into an executable one
and vice versa.

Т.е. страницу невозможно сделать одновременно исполнимой и перезаписываемой, и если страница хоть раз была перезаписываемой, она уже никогда не сможет стать исполнимой. В противном случае вредоносный код сможет внедриться в неё, пока она перезаписываемая, и защита будет прорвана.

[innkeeper]

Class-файлы содержат больше информации, чем "шитый" код. JIT может оптимизировать вызовы методов (инлайнинг), а в современной версии JVM 6.0 временные объекты могут инстанцироваться не в куче, а на стэке, что повышает скорость доступа к ним и работу с ними в разы. Для программы на C++ пришлось бы писать такую оптимизацию вручную, с использованием сторонних библиотек.

Насколько я знаю, JVM написана на С++ (помниться на лекции о C++09 , Бьярн несколько раз заикался о том, что Sun не хочет, чтобы С++ стал медленнее, иначе это плохо отразиться на Java). Смею предположить, что сама JVM наверняка для i686 и откомпилированна, и стандартная библиотека Java именно i686 код.

Если я понимаю что-либо не так, прошу меня поправить.

И ещё один вопрос тогда. Если я в первый раз запущу java приложение на Intel Core Duo, а потом перенесу хард на другую машину с AMD64 (или даже допустим Intel Atom), я получу неработающие приложение? Или каждый раз при запуске я получаю задержку на проверке процессора (как например это делает mplayer)?

[izen.fire]

Насколько я знаю, JVM написана на С++ (помниться на лекции о C++09 , Бьярн несколько раз заикался о том, что Sun не хочет, чтобы С++ стал медленнее, иначе это плохо отразиться на Java). Смею предположить, что сама JVM наверняка для i686 и откомпилированна, и стандартная библиотека Java именно i686 код.

Появится альтернатива C++ в плане переносимости исходников JVM на другие архитектуры и операционные системы — будет продвижение в этом русле. Не появится — не будет.
Перепишите JVM на Modula-2, ну пожалуста.

И ещё один вопрос тогда. Если я в первый раз запущу java приложение на Intel Core Duo, а потом перенесу хард на другую машину с AMD64 (или даже допустим Intel Atom), я получу неработающие приложение? Или каждый раз при запуске я получаю задержку на проверке процессора (как например это делает mplayer)?

Каждый раз при запуске Java-приложение JIT'ится. Неважно, на какой архитектуре загружается/запускается .class-файл —всё будет происходить "как в первый раз" с учётом конкретной архитектуры процессора и объёма памяти.

[innkeeper]

Появится альтернатива C++ в плане переносимости исходников JVM на другие архитектуры и операционные системы

Собственно я к чему весь этот разговор вёл, что так или иначе, Java идёт по верх С++ а значит быть быстрее не может. Байткод ведь для JVM составляется, а не для реальной машины.

[izen.fire]

Собственно я к чему весь этот разговор вёл, что так или иначе, Java идёт по верх С++ а значит быть быстрее не может. Байткод ведь для JVM составляется, а не для реальной машины.

Но ведь исполняется не байткод, а нативный код, получившийся в результате работы JIT. Неважно, на чём написан JIT (JIT и так работает не более 1-5% времени жизни приложения), а важно качество оптимизации нативного кода, получающегося после обработки байткода JIT'ом.

Вот в чём весь цимус.

[innkeeper]

Но ведь исполняется не байткод, а нативный код, получившийся в результате работы JIT. Неважно, на чём написан JIT (JIT и так работает не более 1-5% времени жизни приложения), а важно качество оптимизации нативного кода, получающегося после обработки байткода JIT'ом.

Вот в чём весь цимус.

Ну так всё равно быстрее выполняться не может. Или вы хотите сказать что JVM - компилятор получше gcc? Если так, то опять же надо сравнивать не с быстротой С++ а с тогда уж конкретными компиляторами. Попробовать для сравнения компилятор от Intel.

А статьи, как наример Making Java Technology Faster Than C with LRWP, лишь доказывают, что не все умеют писать хороший код на Си, как это умеют делать в Sun.

И вообще я жду как доведут LLVM :-) По мне это более перстпективный ход для повышения производительности приложений.

[izen.fire]

Ну так всё равно быстрее выполняться не может. Или вы хотите сказать что JVM - компилятор получше gcc? Если так, то опять же надо сравнивать не с быстротой С++ а с тогда уж конкретными компиляторами. Попробовать для сравнения компилятор от Intel.

Ну вот, смотрите:

От: chukichuki
Дата: 26.06.08 15:17

Поверхностный гуглинг дал следующий результат

http://vladweb.narod.ru/help/csharp/csharp_req.htm

Оптимизации, присущие только JIT

Поскольку JIT активизируется во время выполнения, он использует большое количество информации, которую не может использовать компилятор. Это позволяет осуществлять некоторые оптимизации, которые доступны только во время выполнения:

* Процессор-специфические оптимизации — Во время выполнения JIT знает о том, может ли он использовать инструкции SSE или 3DNow. Ваш выполняемый файл будет скомпилирован специально для P4, Athlon или любого другого семейства процессоров. Будучи однажды созданным, тот же код будет совершенствоваться вместе с JIT и машиной пользователя.
* Удаление уровней преобразования логических адресов в физические, т.к. расположение функции и объекта доступны во время выполнения.
* JIT может осуществлять оптимизации через сборки, обеспечивая множество преимуществ, получаемых вами при компилировании программы со статическими библиотеками, но сохраняя гибкость и небольшие последствия использования динамических библиотек.
* Активные inline функции, вызываются чаще, т.к. во время выполнения учитывается управляющая логика. Оптимизации могут обеспечить существенное повышение скорости, и остается еще большое поле для улучшений в следующих версиях.

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

[innkeeper]

Удаление уровней преобразования логических адресов в физические, т.к. расположение функции и объекта доступны во время выполнения

Вы сами можете своими словами объяснить, что это за преимущество такое? Или это преимущество не над компилируемыми языкми, а над другими интерпретируемыми?

Ну а про остальное уже говорили :-) Давайте условимся так, преимущества runtime анализа машины и соответствующей компиляции кода может быть актуально для какого-нибудь Azureus, который используют кто ни попадя. И, честно говоря, непонятно какая может быть оптимизация для Azureus, он там не расчитывает сотни гигабайт информации. А памяти меньше требовать от JVM подозреваю он не станет.

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

[sarutobi]

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

я понимаю, у вас грамотное приложение? серверная часть сейчас стоит на Intel Xeon, что будет через год под нашими нагрузками, я не знаю.
Пожалуйста, соберите мне enterprise продукт на следующих условиях:
Аппаратное обеспечение: Intel Core2Duo 6300, AMD64 x2 5200+ AMD64 4000+
ОС: Linux, Windows XP, Windows 2003 Server
Парк машин обновляется регулярно - в ближайшее время планируется приобретение Core Quad.
Это не надуманная ситуация, это реальность места где я работаю. Сколько сборок Вы мне отдадите, и сколько раз я буду вынужден обращаться к вам за сборкой под конкретную платформу?

[innkeeper]

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

я понимаю, у вас грамотное приложение? серверная часть сейчас стоит на Intel Xeon, что будет через год под нашими нагрузками, я не знаю.
Пожалуйста, соберите мне enterprise продукт на следующих условиях:
Аппаратное обеспечение: Intel Core2Duo 6300, AMD64 x2 5200+ AMD64 4000+
ОС: Linux, Windows XP, Windows 2003 Server
Парк машин обновляется регулярно - в ближайшее время планируется приобретение Core Quad.
Это не надуманная ситуация, это реальность места где я работаю. Сколько сборок Вы мне отдадите, и сколько раз я буду вынужден обращаться к вам за сборкой под конкретную платформу?

Разные ОС это вообще из другой оперы ;-) Хотя опять же, грамотный С++ код позволяет легко решить эту проблему.

А какое собственно enterprise решение вас для такого изменчивого аппаратного обеспечения интересует? Может ему оптимизация для проца и к чорту не далась? Допустим это решения для создания бэкапов (пускай оно супер навороченное со всякими централизованными хранилищами и консолидацией бэкапов и т.п. и т.д.). При оптимизации кода под проц, оно от этого читать с харда быстрее не будет.

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

При каких задачах, оптимизация кода под конкретный процессор даёт больше эффективности? Там где происходят именно вычислительно трудоёмкие задачи (например расчёт экстремумов трёхмерных функций). При любых остальных случаях повысить эффективность работы приложения можно лишь уменьшением потребления памяти.

[deninok]

Судя по названию темы - очередная святая война...

[AMD]

Появится альтернатива C++ в плане переносимости исходников JVM на другие архитектуры и операционные системы

Собственно я к чему весь этот разговор вёл, что так или иначе, Java идёт по верх С++ а значит быть быстрее не может. Байткод ведь для JVM составляется, а не для реальной машины.

Когда ты говоришь это вспоминаю учителя по труду в школе который не хотел ставить оценку выше 8 (У нас десятибальная система)
по его убеждениям 10 имеет бог 9 - учитель а ученикам максимум 8. Тупое мышление.

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

Но для того чтобы стать самым лучшим надо работать и учится десятками годами - но не у всех есть это время.
Зато это делают за нас программисты SUN посредством жавы.

Поэтому если проект будет большой и дорогостоящий (и очень хорошо оплачиваемый ) конечно будет неплохо его сделать на С++ чтобы достичь максимальной скорости

Но некачественный проект на С++ оплаченный в ту же сумму с проектом на жава который будет высококачественным по скорости и качеству не сможет сравнится.

Поэтому начинающие программисты и программистам легче делать качественные и быстрые программы на жава чем глючные и неполноценные на С++

Потом не надо забывать про сервлеты(на жава) они компилируются целиком при запуске а потом месяцами(или годами) уже работают на машином коде скомпилированным оптимально под данную машину.
Так что говорить о тормознутости жава не очень правильно. Что же говорить о скриптовых языках которые до сих пор пользуются большой популярностью.

[innkeeper]

Но некачественный проект на С++ оплаченный в ту же сумму с проектом на жава который будет высококачественным по скорости и качеству не сможет сравнится.

Никто тут ни говорил о денежных затратах и тем более о скорости разработки. Спор в том, что Java как язык позволяет создавать более быстрые программы чем С++. Я ещё раз акцентрирую внимание на быстрые, но никак не быстро.

Поэтому начинающие программисты и программистам легче делать качественные и быстрые программы на жава чем глючные и неполноценные на С++

Ещё раз повторюсь, мы говорили лишь о потенциальных возможностях языка, а программисты тут не причём. Порог начала работы в Java ниже чем в C++, однако не обладая знаниями и на Java не напишешь хорошую программу.

Потом не надо забывать про сервлеты(на жава) они компилируются целиком при запуске а потом месяцами(или годами) уже работают на машином коде скомпилированным оптимально под данную машину.
Так что говорить о тормознутости жава не очень правильно. Что же говорить о скриптовых языках которые до сих пор пользуются большой популярностью.

А никто не говорил, что Java - тормознутая (как раз наоборот, обвинили С++ в тормознутости, хоть и косвенно через NetBeans). Я лишь говорю, что она не может быть качественно быстрее С++.

Нет, я не против Java. Наоборот, я считаю что это великолепное дополнение к существующим инструментариям решения своих задач. Я лишь хотел удостовериться, что я правильно понимаю принципы реализации Java. А в моём понимании качественный код на Java не быстрее качественного кода на С++. Замечу не быстрее. Я даже готов согласиться, что они могут совпадать (переводя на ваш язык поставить оценку 10) по скорости, но не могу согласиться, что Java позволяет создавать качественно быстрые программы по сравнению с С++. Я считаю, что такие фразы - лишь крики фанатиков, которые не хотят до конца понимать всю суть реализации.

P.S. кстати, может быть тему имеет смысл переименовать, а то она вводит в заблуждение.

[innkeeper]

Судя по названию темы - очередная святая война...

Ой, вы знаете, я по сути ничего не знаю о Java и очень хочу начать узнавать. Возможно вы найдёте мой способ не самым эффективным, но он на самом деле и не основной. Мало ли тут найдуться очень умные люди, которые смогут меня подтолкнуть на новый уровень понимания. Я хочу высказывать свои мнения прежде всего для того, чтобы кто-то нашёл у меня ошибки и поправил бы их.

[innkeeper]

Вот, кстати, интересная ссылка пробежала на ЛОРе. Тут есть на что посмотреть. Разные бенчмарки (как раз те, на которых оптимизация кода по CPU сильно играет роль) для разных комбинаций язык-компилятор. Можно тут кстати найти и бенчмарк, в котором Java на первом месте (см. бинарные деревья)

http://shootout.alioth.debian.org/gp4/benc...ll&lang=all

[AMD]

Вот, кстати, интересная ссылка пробежала на ЛОРе. Тут есть на что посмотреть. Разные бенчмарки (как раз те, на которых оптимизация кода по CPU сильно играет роль) для разных комбинаций язык-компилятор. Можно тут кстати найти и бенчмарк, в котором Java на первом месте (см. бинарные деревья)

http://shootout.alioth.debian.org/gp4/benc...ll&lang=all

По ссылке вижу на 6 месте

[diesel]

Вот, кстати, интересная ссылка пробежала на ЛОРе. Тут есть на что посмотреть. Разные бенчмарки (как раз те, на которых оптимизация кода по CPU сильно играет роль) для разных комбинаций язык-компилятор. Можно тут кстати найти и бенчмарк, в котором Java на первом месте (см. бинарные деревья)

http://shootout.alioth.debian.org/gp4/benc...ll&lang=all

По ссылке вижу на 6 месте

вот если там еще memory usage добавить станет интересней: http://shootout.alioth.debian.org/gp4/benc...mp;threadring=1

[sarutobi]

А в моём понимании качественный код на Java не быстрее качественного кода на С++. Замечу не быстрее. Я даже готов согласиться, что они могут совпадать (переводя на ваш язык поставить оценку 10) по скорости, но не могу согласиться, что Java позволяет создавать качественно быстрые программы по сравнению с С++. Я считаю, что такие фразы - лишь крики фанатиков, которые не хотят до конца понимать всю суть реализации.

Ну давай те еще раз от печки и на пальцах пройдемся. То что качество реализации алгоритма у нас одинаковое, что на Java что на C++ - это аксиома. Процессор компьютера выполянет машинный код - это тоже аксиома. Остается перевод алгоритма, записанного на (относительно) высокоуровнем языке в низкоуровневый машинный код. И вот тут выезжает та самая причина, по которой java-реализация может оказаться быстрее, нежели реализация С++. После сборки программы с++ под конкретную процессорную архитектуру (и ОС) она будет исполнятся наиболее оптимально на данной платформе. изменение платформы потребует перекомпиляции. Java-код будет исполнятся без пересборки, с трансляцией в машинный код "на лету". И поскольку JVM на этапе исполнения трансляции известно о платформе все (в отличие от компилятора С++, которому окружение известно на этапе компиляции), код в результате получается более оптимальным (используются конкретные возможности конкретной платформы). Прошу заметить - оптимальным, по скорости исполнения см. аксиому два. И вот за счет оптимальности получается прирост производительности. Кстати, подобный же эффект наблюдается на платформе Mono/.Net - существуют приложения написанные на VBasic.Net котрые выполняются на скорости откомпилированных C++ приложений.

[nestoklon]

И вот за счет оптимальности получается прирост производительности.

И как часто это происходит в реальности?

[/dev/random]

И поскольку JVM на этапе исполнения трансляции известно о платформе все (в отличие от компилятора С++, которому окружение известно на этапе компиляции)

И что же например может быть известно JVM, но неизвестно компилятору C++ ("которому окружение известно на этапе компиляции")?

[RasenHerz]

ничего нового) по-моему, если нужна скорость, то лучше откомпилировать программу из сорцев в gcc с включенной оптимизацией О2 ))) никакая JVM не догонит

[sarutobi]

И поскольку JVM на этапе исполнения трансляции известно о платформе все (в отличие от компилятора С++, которому окружение известно на этапе компиляции)

И что же например может быть известно JVM, но неизвестно компилятору C++ ("которому окружение известно на этапе компиляции")?

Вы разницу между "на этапе исполнения" и" на этапе компиляции" понимаете? или тоже объяснить? Как гентушнику, возможно

[/dev/random]

Вы разницу между "на этапе исполнения" и" на этапе компиляции" понимаете? или тоже объяснить? Как гентушнику, возможно

Разница только в том, что на этапе исполнения уже известно какие _запущены_ программы, и какая часть оперативки/винта занята. Но на этом серьёзной оптимизации не построить. А остальное уже известно на этапе компиляции. Это для гентушника, конечно, который все программы компилит под свою систему. Для опенсуслика или мандрашника, для которых всё уже скомпилировано, разумеется, неизвестно почти ничего.