Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Не собираюсь оспаривать твои высказывания, но объясни мне, пожалуйста, почему тогда абсолютное большинство десктопного софта, написанного на яве работает в разы медленее, чем его аналоги на C/C++? Почему mcirosoft-овский MSDN работает быстро, а IBM-овская справка (на Java) — из рук вон медленно?
IBMовская справка — она не на Java, а на HTML. Там локально запускается web-сервер по которому ходит браузер. Так что все претензии к браузеру на С++.
ГВ>Почему та же история повторяется с парочкой OpenOffice/MS Office?
Скажи, а где в OpenOffice используется Java?
ГВ>UML-рисовалки, это вообще мрак. Если сравнивать Eclipse и MSVC 6.0 — это попросту не смешно. Если ява с такой уверенностью "рвёт" плюсовый код?
Странно, а мы на GEF на Eclipse переписывали тормозючий проект с С++.
Здравствуйте, Cyberax, Вы писали:
C>IBMовская справка — она не на Java, а на HTML. Там локально запускается web-сервер по которому ходит браузер. Так что все претензии к браузеру на С++.
Эээ... Может, я немного не в тему. Видел я эту справку. Какой смысл запускать локальный веб-сервер для HTML?
Здравствуйте, Воронков Василий, Вы писали:
C>>IBMовская справка — она не на Java, а на HTML. Там локально запускается web-сервер по которому ходит браузер. Так что все претензии к браузеру на С++. ВВ>Эээ... Может, я немного не в тему. Видел я эту справку. Какой смысл запускать локальный веб-сервер для HTML?
Там не только статический HTML. Там ещё есть и активный полнотекстовый поиск (который, кстати, работает лучше чем убогий MSDNовский).
Здравствуйте, Sinclair, Вы писали:
S>Сосал почтовый сервер, весь из себя написанный на плюсах и работавший поверх файлухи. (а то! ведь СУБД — это тормоза, они не дают прямого управления IO).
CommuniGate, что ли? Его автор одно время сюда заходил, и расставлял пальцы до плеч. Или не сюда, а в ФИДО?..
S>У меня с реакцией на ассемблер всё в порядке. У меня невротическая реакция как раз на "теоретический предел эффективности", который устроен вовсе не так, как думает Павел. Но объяснить ему это нереально: шаблоны слишком прочны.
Вы пытаетесь доказать удивительные вещи: что программа, между которой и железом несколько слоев абстракции, может работать быстрее, чем программа, которая работает прямо на железе.
А почему бы эти слои абстракции не запустить поверх себя, и так далее до бесконечности, каждый раз увеличивая производительность
Если ослабить ваше утверждение до "плохо написанная программа на ассемблере может работать медленнее, чем хорошо написанная программа на C#", с таким утверждением несложно согласиться. Но только оно тривиально и верно для любой пары языков.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, Sinclair, Вы писали:
S>>Сосал почтовый сервер, весь из себя написанный на плюсах и работавший поверх файлухи. (а то! ведь СУБД — это тормоза, они не дают прямого управления IO).
Pzz>CommuniGate, что ли? Его автор одно время сюда заходил, и расставлял пальцы до плеч. Или не сюда, а в ФИДО?..
S>>У меня с реакцией на ассемблер всё в порядке. У меня невротическая реакция как раз на "теоретический предел эффективности", который устроен вовсе не так, как думает Павел. Но объяснить ему это нереально: шаблоны слишком прочны.
Pzz>Вы пытаетесь доказать удивительные вещи: что программа, между которой и железом несколько слоев абстракции, может работать быстрее, чем программа, которая работает прямо на железе.
нет, он говорит, что VM, в каждую следующую секунжу может нагенерить новый асм, которые будет оптимальнее предыдущего исходя из текущей ситуации. Т.е. VM может покрыть кучу случаев, изменяя машинный код налету, потимизируя, подстраиваясь под платформу, под погоду и настроение юзера. Как rdbms оптимайзят запросы, кароче.
Pzz>А почему бы эти слои абстракции не запустить поверх себя, и так далее до бесконечности, каждый раз увеличивая производительность
Pzz>Если ослабить ваше утверждение до "плохо написанная программа на ассемблере может работать медленнее, чем хорошо написанная программа на C#", с таким утверждением несложно согласиться. Но только оно тривиально и верно для любой пары языков.
Здравствуйте, Cyberax, Вы писали:
C>Там не только статический HTML. Там ещё есть и активный полнотекстовый поиск (который, кстати, работает лучше чем убогий MSDNовский).
Я спросил, зачем веб-сервер нужен Зачем веб-сервер для полнотекстового поиска?
Здравствуйте, Cyberax, Вы писали:
C>Вот что значат тормозные FS в Винде...
А, ну да, конечно. А сиквел сервер, значит, не поверх них работает, а божьей милостью впятеро быстрее шарашит.
Дело не в FS, а в правильности подхода. Смею полагать, что мы с тем же успехом могли бы поднять тот сервер и поверх Оракла на линухе, и всё равно джава порвала бы нативную реализацию поверх файлухи.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pzz, Вы писали:
Pzz>CommuniGate, что ли? Его автор одно время сюда заходил, и расставлял пальцы до плеч. Или не сюда, а в ФИДО?..
Я, честно говоря, за восемь лет уже забыл, как назывался сервер, проработавший у нас два месяца.
Pzz>Вы пытаетесь доказать удивительные вещи: что программа, между которой и железом несколько слоев абстракции, может работать быстрее, чем программа, которая работает прямо на железе.
Совершенно верно, пытаюсь. Нужно просто понять, что "слои абстракции" не "между", а рядом. Я надеюсь, ты в курсе, что сам MSIL код никто не исполняет — он превращается в самый что ни на есть нативный, и исполняется "прямо на железе"?
Pzz>А почему бы эти слои абстракции не запустить поверх себя, и так далее до бесконечности, каждый раз увеличивая производительность
Есть старая байка про то, как оптимизирующий компилятор С++ скомпилировали на себе же. И получили 30% performance gain.
Я надеюсь, понятно, что еще один прогон не дал бы еще 30%?
Pzz>Если ослабить ваше утверждение до "плохо написанная программа на ассемблере может работать медленнее, чем хорошо написанная программа на C#", с таким утверждением несложно согласиться. Но только оно тривиально и верно для любой пары языков.
Это совсем другое утверждение, чем делал я.
Я защищаю примерно такое утверждение: "оптимизация декларативной программы дает больший выигрыш, чем императивной. И выигрыш тем больше, чем ниже уровень императивной программы". В частности, ассемблер улучшить почти что никак не удастся. Байки про "хорошо написанную программу на ассемблере" рассказывайте кому-нибудь другому.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
PD>>Мне что, делать больше нечего, кроме как вычисление процентов распараллеливать ?
AVK>Понятно. Тогда получается, что все твои утверждения получается рассматривать только как пустой звук.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, netch80, Вы писали:
N>>Да уж... qsort3 из этого источника ничуть не проще хорошей сишной реализации. Наоборот, понять, что там творится, требует заметной подготовки. FR>Если на Си реализовать тот же алгоритм, будет сложнее.
Держу перед глазами сишный код. По-моему, он проще.
N>>А сравнение с C/C++ реализацией на чём-то вроде vector опущено сознательно? FR>Так давай сравнивай никто ни мешает.
Не-а, это ведь ты агитируешь:) так покажи реально полезное сравнение, а не между хаскелем и хаскелем.
Здравствуйте, IT, Вы писали:
IT>В 20 и больше я знаю как. Только мне для этого не достаточно будет покататься в маршрутке.
А я в своей задаче не знаю. И не уверен, что этот способ существует вообще. Более того, практически уверен, что он не существует. Так что покамесь буду оптимизировать то, что есть, потом посмотрим, что из этого получилось, а потом... потом видно будет. . Распараллеливать придется, однако. Только не с помощью AsParallel .
Здравствуйте, Sinclair, Вы писали:
C>>Вот что значат тормозные FS в Винде... S>А, ну да, конечно. А сиквел сервер, значит, не поверх них работает, а божьей милостью впятеро быстрее шарашит. S>Дело не в FS, а в правильности подхода. Смею полагать, что мы с тем же успехом могли бы поднять тот сервер и поверх Оракла на линухе, и всё равно джава порвала бы нативную реализацию поверх файлухи.
Обычно "взрослые" SQL-сервера стараются общаться с диском напрямую, насколько это возможно. Вплоть до использования своей собственной партиции, на которой нет никакой файловой системы.
Это как раз пример, опровергающий вашу точку зрения. Нормальная файловая система старается оптимизировать доступ к диску — используя кеши, опережающее чтение и т.п. В среднем это дает выигрыш, но у SQL-серверов своя собственная идея, как наиболее эффективно работать с диском, так что обычная автоматическая оптимизация им только мешает.
Т.е., SQL-сервер работает с диском быстрее именно благодаря тому, что он работает с ним на более низком уровне.
Совершенно аналогично, есть код, которому поможет рантаймовая оптимизация, встроенная в дотнет, а есть, которому только помешает.
P.S. Что до самой идеи держать почту в файлах, а не в SQL-базе, в ней есть свои преимущества. Такая конструкция значительно проще и прозрачнее, и если в ней что-то сломается, проще починить, что немаловажно для администрирования. К тому же, юниксовские файловые системы довольно быстрые при таком паттерне использования, в отличии от.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, netch80, Вы писали:
N>>Задача придолбаться?;)) Проще, понятнее — верю. Эффективнее — сомнительно. Реально, фильтрация на списках будет занимать дохрена копирований, рекурсия может переполнить стек при кривой реализации... в общем, эффективность такого должна быть не выше (а то и ниже) эффективности пузырька, который пишется не менее просто и понятно.:)) Или докажите обратное (желательно на практике;))
FR>Очень полезно дочитать тему перед тем как придплбливатся :)
Там нет сравнения с C или даже C++.
FR>Так что все мимо.
S>Ну прикол-то в том, что если программа сформулирована в терминах mov, add, jmp и т.д, то простор для ее оптимизации крайне мал.
Ты когда-нибудь видел задачу, которая могла бы быть сформулирована в терминах mov, add, jmp и т.д ? Я таких задач в предметной области не встречал, разумееется, драйверы и прочие средства доступа к железу не в счет.
На тебе банальную задачу умножения матриц и сформулируй ее в терминах mov, add, jmp и т.д. Подчеркиваю, сформулируй, а не напиши програму. А мы посмотрим, что из этого вышло
>Да, процессоры сейчас выжимают максимум из этого
Из чего они выжимают, ты что говоришь-то ? Из себя, что ли ? Или из своих собственных команд add. mov и т.д. ? Вот сижу и вижу — процессор пытается из самого себя выжать максимум. Меня это даже пугает немного — а вдруг чего-то выжмет
> но у них есть существенные ограничения как по ресурсам, которые можно на это потратить, так и по возможным действиям, которые они могут выполнить.
Это у процессоров ограничения по действиям, которые они могут выполнить ? Ну , кажется, приехали. У процессоров , значит, ограничения, а вот если на этих процессорах исполнять управляемый код со всеми наворотами, то эти ограничения куда-то исчезают и открываются у процессоров дополнительные возможности, так , что ли ? Ну и ну!
S>А вот если задача сформулирована декларативно, то как раз можно и алгоритм поменять, и доступ к данным ускорить, и распараллелить и всё что угодно.
Можно. Алгоритм всегда поменять можно, было бы на что менять. И доступ тоже поменять можно. И распараллелить. Поверь, все это вполне можно и без всяких управляемых сред. Это еще лет 20 назад умели и даже раньше.
S>Более того, во многих задачах невозможно заранее предложить оптимальное решение в терминах mov, add, jmp и т.д.
И неоптимальное тоже — см. выше, потому что так никто задачи не формулирует. И зря ты пытаешься доказать, что я это утверждаю. Я лишь одно утверждал — есть некий теоретический предел, им является идеально написанная программа на ассемблере. На любом языке с любыми средствами лучше сделать нельзя. При этом я вовсе не утверждаю, что знаю, как такую программу написать. Это лишь теорема о существовании. Но теорема верная. И из нее вовсе не следует, что программы надо писать на ассемблере.
>Просто потому, что еще нет информации о том, в каких условиях будет алгоритм выполняться.
Если он на нетипичном процессоре или на иной архитектуре может выполняться — я со скрипом, но соглашусь. Потому что не знаю. что там хорошо, а что плохо. (В скобках : если буду знать — не соглашусь) Если же речь идет об обычной архитектуре, то не соглашусь. Windows NT-Vista, как тебе известно должно быть, написана так, что кроме HAL, все остальное от архитектуры не зависит. И работает она на x86, x64, а до этого были Alpha, MIPS, Power PC.
>Потому, что, к примеру, параллелить на 1 ядре — это гарантированная потеря производительности.
Грандиозная мысль! Я бы сам никак не догадался . Но , к твоему сведению, узнать число процессоров через Win32 совсем не сложно. См. мой ответ IT с примером программы.
>И непараллелить при 4 ядрах — тоже гарантированная потеря.
А вот до этого я не догадался. Я как-то до сих пор считал, что параллелить можно либо распараллеливаемые алгоритмы, либо массовые операции. А ты, похоже, дай тебе 4 ядра — возьмешься параллелить все, что угодно. Успехов
>А никакого способа автоматически трансформировать mov/add/jmp так, чтобы они были оптимальны для 1/2/4 ядер наука не знает. Зато знает способы делать это в том случае, если программа написана в декларативном стиле.
Посмотри мой пример. Там хоть и не mov и не add (опять борьба с ветряными мельницами), но вполне-таки распараллелено, и без всякого декларативного стиля. Без LINQ. Без интерфейсов. И даже (о ужас!) без классов. Кошмар просто
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Вообще-то такое называется провокацией . Ладно. Будем считать, что провокация твоя удалась
Это не провокация и уж тем более не удавшаяся. С заданием ты не справился, а подменил его своим, подогнанными под себя.
PD>Но процентами и провайдерами я все же заниматься не буду.
И совершенно напрасно. Эта примитивная задачка достаточно сложна для того, чтобы на распаралеливание её в императивном стиле на неё потратить не 20 минут, а несколько больше. При этом мы бы увидели как 80 строк императивного кода лекго превращаются в 150-200. И ещё бы мы увидели, что задеревьями лес потерялся бы окончательно. В примере с Linq 90% кода — это алгоритм. В императивном от алгоритма примерно процентов 20%. Оптимизации уменьшают эту долю ещё в разы. А теперь предположим, что такого кода как 25 строк на linq у меня 2000 строк. Императив + оптимизации увеличат этот код минимум раз в 5, если не больше. Итого 10000+ строк. Full time job по поддержке такого кода для какого-нибудь индуса — это обычное дело. Ещё на забудем про QA team и тогда уж точно манагеров. Куча народа, на внесение изменений тикет за пол года вперёд и поехали.
PD>Насколько я понимаю, AsParallel — это из .Net 4.0, так ?
Это PLinq, CTP доступен здесь.
PD>Ray Tracer мне изучать недосуг, поэтому я просто распараллелил вычисление сумм красных компонент по столбцам окна. Зачем там эти суммы — а просто, чтобы было что делать .
Ну и зачем это надо? Тебя же просили распаралелить конкретный код, чтобы потом сравнить с существующим. А с чем мы теперь будем сравнивать? Опять с твоими домыслами?
PD>Вот код
Свят, свят, свят. Давненько я не видел C. Жуть. От звёздочек и кучи конвенций аж в глазах рябит.
PD>А теперь вопросы к тебе.
Ты сначала сделай то, что тебя просили и мы это обсудим, а потом будешь свою мерялку доставать.
Неясность изложения обычно происходит от путаницы в мыслях.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Воронков Василий, Вы писали:
C>>Там не только статический HTML. Там ещё есть и активный полнотекстовый поиск (который, кстати, работает лучше чем убогий MSDNовский). ВВ>Я спросил, зачем веб-сервер нужен Зачем веб-сервер для полнотекстового поиска?
А так проще всего. Предлагай другие варианты.
Здравствуйте, netch80, Вы писали:
N>Держу перед глазами сишный код. По-моему, он проще.
На си совсем другой алгоритм, несовпадающий кстати и с первым вариантом на хаскеле
N>>>А сравнение с C/C++ реализацией на чём-то вроде vector опущено сознательно? FR>>Так давай сравнивай никто ни мешает.
N>Не-а, это ведь ты агитируешь так покажи реально полезное сравнение, а не между хаскелем и хаскелем.
Я не агитирую, тем более за хаскель. Это тебе показалось что нужно сравнить еще и c C++,
пожалуйста я не мешаю. Хотя могу показать вариант на близком к C++ D
T[] qsort(T)(T[] t)
{
if(t.length == 0)
return [];
auto x = t[0];
auto xs = t[1 .. $];
return qsort(filter!((T a){return a < x;})(xs))
~ [x] ~
qsort(filter!((T a){return a >= x;})(xs));
}
Из которого видно что хаскелю он по выразительности уступает, на C++, будет еще чуть хуже.
Здравствуйте, Sinclair, Вы писали:
C>>Вот что значат тормозные FS в Винде... S>А, ну да, конечно. А сиквел сервер, значит, не поверх них работает, а божьей милостью впятеро быстрее шарашит.
А он работает с файлами на блоковом уровне, обходя почти все механизмы FS.
S>Дело не в FS, а в правильности подхода. Смею полагать, что мы с тем же успехом могли бы поднять тот сервер и поверх Оракла на линухе, и всё равно джава порвала бы нативную реализацию поверх файлухи.
У меня вот прямо сейчас есть хранилище документов на Линуксе, которое пользователи мучают в особо извращённой форме. После перехода с блобов в базе данных на хранилище в файловой система производительность поднялась в 4 раза. После того, как для отдачи этих файлов я подключил lighttppd — производительность поднялась во столько раз, что даже мерить лень.
Про сравнение производительности виндовых FS и линуксовых я тут как-то уже писал. Разница легко может быть в десятки раз, так что ничего удивительного.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Тогда и к тебе те же вопросы, что я задал IT в
Сначала я подожду, когда ты приведешь то, что тебя просили. Это во-первых. А во-вторых, как напишешь императивный аналог алгоритма, что IT описал, ты сделаешь точно такое же как у IT описание своего собственного алгоритма, который ты хочешь увидеть в функциональной форме.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
Ну и зачем это надо? Тебя же просили распаралелить конкретный код, чтобы потом сравнить с существующим. А с чем мы теперь будем сравнивать? Опять с твоими домыслами?
Если нам не помогут, то мы тоже никого не пощадим.
