Сравнение производительности различных сборок OOo

>> Странно, а почему под мегарулезной макосью gcc "ощутимо не сливает"?

> мегарулезая макось - один большой тормоз

И как это она у меня не тормозит? Может быть, потому что я не использую хакинтош?

> происходит из-за использования кнута
Кнут поперхнулся и пытается вспомнить, когда это он кодил для мелкософта

>вообще то допустимы обе формы репозитОрий и репозитАрий.

хохохо, кто-то еще захотел славы сусеров кототроллей

> Очень просто. Если ты пишешь программы не только для x86 и не для одной ОС и тебе надо чтобы код работал везде - естественный выбор - GCC.

Естественный выбор в этом случае это написание кода, который собирается на любом компиляторе.

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

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

рули на винфак :)

>А в режиме горячего старта производительность всех трех представленных windows-сборок оказалась выше на 44%! Автор тестирования полагает, что такая несправедливость происходит из-за использования компилятора MSVС9, который в данном случае оказался эффективнее GCC, используемого в linux-сборках.

а не из-за винды случайно?

А где же Suse Go-oo ?

> И как это она у меня не тормозит? Может быть, потому что я не использую хакинтош?

у меня тоже не хакинтош - mac-mini

> есть мнение что она тормозит чуть больше других десктопных линуксов

Ну так, на дебиане же основана!

> возьми и проверь сам

А не линкует ли MSVC сборку с какими-нибудь постоянно загруженными в Win библиотеками, аналоги которых, в случае Linux, подгружаются в момент старта ? Например, библиотеки графического интерфейчас какие-нибудь...

> Мы дождемся от тебя версий компиляторов, описание тестов, и как правильно подсказали - ключей? На ссылки msvc для avr даже не надеюсь...

пользуйся гуглем - я это уже на ЛОР писал, специально для тебя повторяться не буду

> Естественный выбор в этом случае это написание кода, который собирается на любом компиляторе.

Тоже вариант, но изредка такое условие выполнимо... :) Что касается GCC, допустим он не может сравниться по скорости с msvc. Но есть же ICC for Linux, который совместим с GCC и от него вполне можно ожидать сравнимой с MSVC производительности...

> да "оптимизированные". Для одной платформы. И полностью наплевав на стандарты.

Какие такие стандарты ? MSVS лучше стандарты держит, почитай примеры у Саттера.

Надо же! И у меня мак мини. Старенький MA608LL/A. И не тормозит.

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

ЛОЛ

> Надо же! И у меня мак мини. Старенький MA608LL/A. И не тормозит.

значит ты тормозишь с той же скоростью

>Но есть же ICC for Linux, который совместим с GCC и от него вполне можно ожидать сравнимой с MSVC производительности.

только на процессорах Intel и о совместимости там речи не идет, нужна гора патчей для того чтобы собрать например ядро

> Сколько программистов собралось! Почему никто не спросил ключи GCC?

Посмотри в spec.rpm или аналоге для deb.

>> Надо же! И у меня мак мини. Старенький MA608LL/A. И не тормозит.

> значит ты тормозишь с той же скоростью

Вы-таки уже доставили мне первый лулз? Улыбнуло.

А по существу есть что сказать?

> Но есть же ICC for Linux, который совместим с GCC и от него вполне можно ожидать сравнимой с MSVC производительности...

На Intel по собственному небольшому опыту - не сравнимой, а выше.

> Вы-таки уже доставили мне первый лулз? Улыбнуло.

очень старался - рад, что получилось

> А по существу есть что сказать?

вы таки хотите сказать, что xCode, например, не тормоз?

> вы таки хотите сказать, что xCode, например, не тормоз?

Мухи отдельно, котлеты отдельно. Среда разработки отдельно, компилятор отдельно.

> только на процессорах Intel и о совместимости там речи не идет, нужна гора патчей для того чтобы собрать например ядро

Понятное дело что на intel... :) Про гору патчей, честно, не знал... Всегда казалось что вроде как бы совместимы по отзывам, бенчмарки ядер на разных компиляторах глядел, там про патчи не упоминали... Спасибо за инфу :)

> Мухи отдельно, котлеты отдельно. Среда разработки отдельно, компилятор отдельно.

тогда да - голая ОС без запущенных приложений не тормозит

> Странно, а почему под мегарулезной макосью gcc "ощутимо не сливает"?
Можт из за того, что можно к gcc бэкэнд из llvm подрубить? Кстати, а в Лине есть возможность llvm юзать для сборки пакетов?

> ОС без запущенных приложений не тормозит

Так вот Вы кто - Капитан Очевидность!

Только что Вы говорили о производительности компиляторов. А сейчас Вы перескочили на производительность приложений.

Это называется ignoratio elenchi - подмена тезиса.

>А не линкует ли MSVC сборку с какими-нибудь постоянно загруженными в Win библиотеками, аналоги которых, в случае Linux, подгружаются в момент старта

таки вот именно поэтому я выше писал что нужно было тестить не на убунте.

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

в сусе же например подгружается java, kdelibs, gnomelibs во время старта системы и потом работа происходит гораздо быстрее, в том числе холодный старт

Жаль, что они про Инфру не знают.

> Только что Вы говорили о производительности компиляторов. А сейчас Вы перескочили на производительность приложений. Это называется ignoratio elenchi - подмена тезиса.

это называется сарказм, вы хотите сказать xCode собран не gcc? или что xCode писался по другим принципам чем сама ОС? да и xCode это только единичный пример, из того, что сразу вспоминается - примитивный пример wxWidgets наглухо вешал весь Mac OS X, а так кнопки reset нет - пришлось выдергивать питание, про скорость работы SmartSVN, MacCVS и т.п. я вообще умолчу

А под вендой антивирусник включали, или тест проходил в вакууме?

> надо флажечки у gcc подкрутить.

флажочки или фляжечки?

Что такое по-англицки Red Herring, знаете?

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

Компиляторы отдельно. Приложения отдельно.

> Компиляторы отдельно. Приложения отдельно.

по вашей логике компиляторы никак не связаны с приложениями? на чем тогда проверять?

да и вообще мы вроде Mac OS уже обсуждаем, а не "Компиляторы/Приложения", чем бы вы не объясняли, но стандартный набор приложений в Mac OS X гораздо "тяжелее" того же набора в Linux и Windows, так что фтопку

> по вашей логике компиляторы никак не связаны с приложениями?

Корреляцию надо обосновывать для каждого конкретного случая.

> на чем тогда проверять?

На 100% одинаковом коде, запущенном в реальных эксплуатационных условиях. Не "сферических" условиях. Типа запустили бы ОО.о на офтопе при реально работающем "антивирусе Кашперовского". А рядом бы сборку для мака без иксов которую, для аквы. И, естественно, без антивируса и прочей виндовозной дряни - для юникса это не нужно.

> стандартный набор приложений в Mac OS X гораздо "тяжелее" того же набора в Linux и Windows

Да? А для меня этот "Стандартный набор приложений" - Eclipse.

(С чем еще сравнивать, если под офтопик и близко нет таких профессиональных музыкальных программ, как для мака?)

И чем же Eclipse отличается для Mac OS X и Windows? Что там в SWT они "тяжелее" (с) сделали. Просто интересно.

> И чем же Eclipse отличается для Mac OS X и Windows? Что там в SWT они "тяжелее" (с) сделали. Просто интересно.

никто не спорит - можно вообще Mac Ports использовать, но под "стандартный"( обратите внимание на это слово - это важно ) я имел ввиду то, что используется в подавляющем числе случаев, и в данном случае Eclipse не катит - катит xCode, т.к. он "родной" как по внешнему виду, так и по назначению, и имеет все средства для разработки Mac OS-специфичных приложений

Вы так и не ответили на мой вопрос, а опять изменили тезис.

> Вы так и не ответили на мой вопрос, а опять изменили тезис.

ответил в самом начале, могу дополнить ответ - да, универсальная программа на Java должна работать одинаково на всех ОС, которые поддерживает Java, не буду с этим спорить

> Ходит слух, что в следующей версии ООо 3.1 разработчики обещают множество полезных и приятных исправлений, положительно влияющих на производительность.

Было бы неплохо. А то то, что ms office 2003 под wine шустрее - это несерьёзно.

> устал каждому ламеру объяснять - работаю я( и в винде тоже наравне с Linux и Mac OS ), насчет версии и т.п. - возьми и проверь сам

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

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

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

В Windows _гораздо_ лучше организован DLL cash, поэтому и скорость "горячего" старта больше. А компиляторы тут ни при чем, хотя GCC фиговый ещё.

--седайко стюмчик

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

> Ну какая может быть производительность у офиса? Его производительность равна производительности самого медленного звена — наборщика!

Так может говорить только человек, который использует компьютер как пишущую машинку.

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

Это когда было то? Для 2005 и тем более 2008 студии это не так.

Intel® C++ Compiler Professional Edition for Linux

а под этим собираеться?

> В Windows _гораздо_ лучше организован DLL cash

Цитируете Профессора?

С другой стороны, файловые системы в UNIX и Linux лучше. Лучше и сетевой стек.

Linux - это прежде всего сервер приложений. Как и UNIX.

Что же касается числодробильни, то спецкомпиляторы для Intel и рисков покошернее мелкософтовского поделия будут. Чей-то не видно широкоразрекламиронанного офтопа для "научников-вычислителей". А все Linux, Solaris и AIX.

компиляторы С++ от MS наиболее четко следуют стандартам.

В отличие от гыцаца и борланд