Здравствуйте, D. Mon, Вы писали:

DM>Как я и сказал:
DM>"The places where NASA scientists have used Java for this mission is all on the ground side right now."
DM>"The Rover itself has a computer onboard. There's no Java in that computer now."

Ты целиком процитируй, а не вырывай из контекста:

Q:Are they actually commanding the Mars Rover with Java?

A: For the command and control system, big parts of it are this rather large Java application. There are a lot of parts involved in this. The Rover itself has a computer onboard. There's no Java in that computer now. But on the ground-side, there are a number of parts of the whole command and control chain that goes out to the Rover that's done in Java. It's not like every last piece of every subsystem is based on the Java code. Great big pieces of it are. In particular, all the data visualization, user interface front-end stuff and I believe a whole lot of the database stuff is.

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

А про то, что джаву "послали в космос" я и не говорил.

Здравствуйте, Воронков Василий, Вы писали:

ВВ>Здравствуйте, Pavel Dvorkin, Вы писали:

ВВ>Блин, я вас читал-читал, а как все банально заканчивается

Устал


ВВ>Правда жизни в том, что таких задач становится все меньше и меньше. Вон, помнится, была статья — причем год или два назад — даже луноход какой-то под управлением джавы работал. Все-таки сейчас немного меняются представления о производительности, оптимизации и пр.
ВВ>Сейчас в большинстве случаев не надо байты и тики считать — приложения тормозят не потому что какой-то алгоритм на си-шарпе написан, а не асме, а из-за кривой архитектуры.

Гм. Вообще-то не вижу связи между кривой архитектурой и языком.


>Что в осном народ-то пишет? Бизнес-приложения, распределенные приложения, всякие там корпоративные шины и проч., веб-сервисы и другую подобную дрянь. Там совсем другие проблемы возникают, на другом уровне. Если, к примеру, у тебя плохо продумана связь с каким-нибудь нодом, идет слишком частый обмен пакетами, некорректно обрабатывается таймаут нода, нет кэширования и пр. — тебе тут не поможет переделка твоего приложения на более низкоуровневый асм.

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

ВВ>А теперь представь — вот люди пишут всякие ESB, передают тонны ХМЛя (ХМЛя, понимаешь? ), а ты их пытаешься убедить, что "существуют задачи, для решения которых использование высокоуровневых средств... неэффективно и нецелесообразно". Как на фиг высокоуровневые средства, у нас сплошной ХМЛ, блин

Со всем можно согласиться, но... Есть же задачи, в которых нет тонн XML и т.д. Пусть их становится меньше (меньше в каком смысле — меньше количество програмистов, ими занимающихся или меньше их роль ? со вторым не согласен, первое бесспорно).

Проблема же в том, что адепты этих новых технологий претендуют на их универсальность для всех задач. Тому же AndrewYK просто смешно смотреть на Win32 код — именно потому, что он не те средства (язык, АПИ) использует, что ему надо. Если бы он сказал — для твоей задачи это хорошо, для других — не годится — я бы немедленно согласился, тут и сказке конец. Я разве предлагал web-сайты на С++ писать или XML на ассемблере парсить ? Но нет, подайте им все, они на меньшее не согласны, а поэтому все, что под их методы не подходит — им смешно. Вот я и пытаюсь побудить их просто зафиксировать это простенькое утверждение — независимо от того, какие сферы покрывает то или иное направление.


ВВ>И в итоге чего ты хочешь добиться? Никто не отрицает, что в принципе да, есть задачи для которых подходят более низкоуровневые средства. Но вы разве это обсуждаете? Статистику использования технологий что ли составляете? Речь-то о перспективах, о развитии, о тенденциях. И тенденция такова, что таких задач становится все меньше. Гораздно меньше. Причем в тех областях, в которых использования какого-нибудь дотнета раньше даже помыслить было нельзя.



ВВ>И будет еще меньше. Сейчас у банальной игровой приставки — под которую игры выпускают, кстати, в "обрезанном" по сравнению с PC варианте — прозводительность терафлопами мерится. О чем тут можно говорить-то? Какой асм?

Не знаю насчет игровых приставок, а вот в моей задаче асм будет на днях. Не в чистом виде, а через intrinsic. Для реализации SSE2. Распараллеливание, так сказать, на одном процессоре, и даже без всяких потоков. Тест показал примерно 3.5- кратный выигрыш

ВВ>Собственно, такова позиция твоих оппонентов, как я ее понимаю. И я с ней согласен. А вот твою позицию я не очень понимаю. Какой смысл все сводить к тому, что "есть задачи для к-х асм подходит"? Ну да, пока еще есть. Но мне действительно кажется, что ты переоцениваешь роль и количество таких задач.

Из того, что большинство задач — это задачи бизнеса, еще не следует, что все остальное вымирает.

Здравствуйте, Pavel Dvorkin, Вы писали:


PD>Проблема же в том, что адепты этих новых технологий претендуют на их универсальность для всех задач. Тому же AndrewYK просто смешно смотреть на Win32 код — именно потому, что он не те средства (язык, АПИ) использует, что ему надо. Если бы он сказал — для твоей задачи это хорошо, для других — не годится — я бы немедленно согласился, тут и сказке конец. Я разве предлагал web-сайты на С++ писать или XML на ассемблере парсить ? Но нет, подайте им все, они на меньшее не согласны, а поэтому все, что под их методы не подходит — им смешно. Вот я и пытаюсь побудить их просто зафиксировать это простенькое утверждение — независимо от того, какие сферы покрывает то или иное направление.

Есть такая штука, как правила и исключения. Так вот, правило универсально, даже если из него есть исключения. Если новая технология покрывает 90% задач или больше — она универсальна, а всё не попавшее в область покрытия — это исключения.

И, да, смешно, когда пытаются сделать то, что мы можем сделать одной строкой кода — листингом на две страницы на асме. При этом, человек, который пишет на асме сам загоняет себя в угол — ему больше некуда оптимизировать. Всё, точка. А нам — есть куда. Мы сначала можем посмотреть на С++ или Erlang. А потом и на ассемблер. Если вдруг это понадобится.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Проблема же в том, что адепты этих новых технологий претендуют на их универсальность для всех задач. Тому же AndrewYK просто смешно смотреть на Win32 код — именно потому, что он не те средства (язык, АПИ) использует, что ему надо.

Не надо фантазировать. Смотреть мне не смешно, а, скорее, грусто. Это во-первых. А во-вторых, и я тебе уже об этом говорил, всю специфику Win32 я игнорирую намеренно, потому что иначе ты тут же переведешь разговор на обсуждение технических мелочей, как ты в очередной раз продемонстрировал здесь же в разговоре с Синклером.

PD>Но нет, подайте им все, они на меньшее не согласны

Цитату в студию, где я предлагал все писать в функциональном стиле.

PD>, а поэтому все, что под их методы не подходит — им смешно.

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

Здравствуйте, Aen Sidhe, Вы писали:

AS>Есть такая штука, как правила и исключения.

Есть.

>Так вот, правило универсально, даже если из него есть исключения. Если новая технология покрывает 90% задач или больше — она универсальна, а всё не попавшее в область покрытия — это исключения.

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

А кстати, такой вопрос. Ты утверждаешь 90:10. Я точных цифр не знаю, но пусть так. Но если из этих 90% исключить все приложения для www, которые никто никогда ни на асме, ни на С++ не предлагал писать , каково будет отношение между тем, что останется от этих 90% и тем, что сейчас входит в 10% ?

>При этом, человек, который пишет на асме сам загоняет себя в угол — ему больше некуда оптимизировать. Всё, точка. А нам — есть куда. Мы сначала можем посмотреть на С++ или Erlang. А потом и на ассемблер. Если вдруг это понадобится.

Прелесть! Умри Денис, лучше не скажешь.

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

А вам — есть куда. Вы сначала нечто такое, что раз в N медленнее работает и в M раз больше памяти потребляет, напишете (не важно на чем, не будем уточнять). И, конечно, у вас теперь есть великолепные перспективы для улучшения — еще бы! Можно потом на С++ переписать и гордо заявить — вот, мы оптимизировали, какие мы молодцы. А потом и на асме переписать.

А зачем на асме-то переписать ? Правильно. Чтобы наконец загнать себя в угол!

Здравствуйте, samius, Вы писали:

S>Павел! понятия эффективности и целесообразности без специальных оговорок весьма субъективны.

Конечно, я это понимаю.

S>Подпись под такой декларацией позволит и дальше оппонентам иметь разные мнения об эффективных и целесообразных мерах для решения одной конкретной задачи.

Ну мнение-то никто не запрещате иметь какое-угодно, вне всякой связи с этой подписью.


>А факт существования таких задач из пунктов 1) и 2), где по поводу эффективности сойдутся большинство мнений — не интересен.

Мне не это интересно. Я другое имею в виду. Я-то согласен с тем, что писать с использованием низкоуровненвых средств не всегда имеет смысл. Иными словами, я на их мир не покушаюсь. А вот оппоненты мои на мой мир покушаются — они его попросту считают смешным.

Несколько более жестко высказываясь — если бы мне дали власть решать, что и где использовать, я бы отнюдь не стал запрещать им использовать C# , Linq , и т.д. Но , боюсь, дай им власть — они бы мне просто запретили бы C++ и asm.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Здравствуйте, Aen Sidhe, Вы писали:

AS>>Есть такая штука, как правила и исключения.

PD>Есть.

>>Так вот, правило универсально, даже если из него есть исключения. Если новая технология покрывает 90% задач или больше — она универсальна, а всё не попавшее в область покрытия — это исключения.

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

Способ распределения задач нас сейчас не интересует — это некая абстракция.

PD>А кстати, такой вопрос. Ты утверждаешь 90:10. Я точных цифр не знаю, но пусть так. Но если из этих 90% исключить все приложения для www, которые никто никогда ни на асме, ни на С++ не предлагал писать , каково будет отношение между тем, что останется от этих 90% и тем, что сейчас входит в 10% ?

Однако, с чего вдруг, мы будем убирать www приложения? Новые технологии спокойно позволяют писать такие приложения с использованием тех же средств, что и для десктопных приложений. Более того, я лично видел несколько отлично работающих сайтов на С++ (ActiveX, COM, etc).

>>При этом, человек, который пишет на асме сам загоняет себя в угол — ему больше некуда оптимизировать. Всё, точка. А нам — есть куда. Мы сначала можем посмотреть на С++ или Erlang. А потом и на ассемблер. Если вдруг это понадобится.

PD>Прелесть! Умри Денис, лучше не скажешь.

PD>Человек, который пишет на асме (в предположении, что он хорошо пишет) — загоняет себя в угол, потому что написав хорошо на асме, он действительно для данного железа ничего больше уже сделать не сможет — все, выжали все, что можно.

Только вот проблема. Сменилось железо и всё переписывать? Ну удачи, я такого пути не понимаю.

PD>А вам — есть куда. Вы сначала нечто такое, что раз в N медленнее работает и в M раз больше памяти потребляет, напишете (не важно на чем, не будем уточнять). И, конечно, у вас теперь есть великолепные перспективы для улучшения — еще бы! Можно потом на С++ переписать и гордо заявить — вот, мы оптимизировали, какие мы молодцы. А потом и на асме переписать.

Вот только, есть мнение, память и процессор новые дешевле месяца твоей работы. Не так ли? Это раз. Два, N и M уже сейчас стремятся к 1, если использовать нормальные алгоритмы и архитектуры.

PD>А зачем на асме-то переписать ? Правильно. Чтобы наконец загнать себя в угол!

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

Во всех виденных мною "тормозах", "пожираниях памяти" так или иначе были проблемы с архитектурой и/или реализацией.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Здравствуйте, samius, Вы писали:

>>А факт существования таких задач из пунктов 1) и 2), где по поводу эффективности сойдутся большинство мнений — не интересен.

PD>Мне не это интересно. Я другое имею в виду. Я-то согласен с тем, что писать с использованием низкоуровненвых средств не всегда имеет смысл. Иными словами, я на их мир не покушаюсь. А вот оппоненты мои на мой мир покушаются — они его попросту считают смешным.
Мне все же кажется, что это не так. Оппоненты пытаются донести что использование высокоуровневых средств более эффективно в большинстве задач, если речь идет не о железе. Эффективно — значит при схожей или чуть меньшей производительности решения оно будет дешевле и быстрее по срокам.

PD>Несколько более жестко высказываясь — если бы мне дали власть решать, что и где использовать, я бы отнюдь не стал запрещать им использовать C# , Linq , и т.д. Но , боюсь, дай им власть — они бы мне просто запретили бы C++ и asm.
Не совсем так. Фигурально выражаясь, они пытаются усадить Вас за BMW с тем чтобы Вы могли сравнить ее с ВАЗ-ом, но Вы отказываетесь, аппелируя тем, что у BMW больше расход и что надо просто уметь ездить на ВАЗ-е. В свою очередь, оппонентам не будут интересны Ваши аргументы в пользу ВАЗ-а, пока вы как-следует не покатаетесь на BMW. Они не призывают Вас ездить на BMW, они просто хотят, чтобы Вы почувствовали разницу.

Здравствуйте, samius, Вы писали:

S>Мне все же кажется, что это не так. Оппоненты пытаются донести что использование высокоуровневых средств более эффективно в большинстве задач, если речь идет не о железе. Эффективно — значит при схожей или чуть меньшей производительности решения оно будет дешевле и быстрее по срокам.

Так я всего-то и хочу — чтобы они признали, что есть и другие задачи, где это неверно. А они не хотят . Похоже, в принципе не хотят.

S>Не совсем так. Фигурально выражаясь, они пытаются усадить Вас за BMW с тем чтобы Вы могли сравнить ее с ВАЗ-ом, но Вы отказываетесь, аппелируя тем, что у BMW больше расход и что надо просто уметь ездить на ВАЗ-е.

Сравнение некорректно. Если уж сравнивать, то надо сравнивать BMW с неким автомобилем, который хорошая фирма могла бы сделать ручной сборкой, а не на конвейере, и с деталями, сделаннными специально для этого автомобиля, а не отштапованными. Иными словами, сравнить BMW с неким гоночным автомобилем. Это и будет вполне подходящее сравнение — BMW штука хорошая, но выжать из двигателя внутреннего сгорания и прочего то, что они могут сейчас дать, он и близко не может.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Здравствуйте, samius, Вы писали:

S>>Не совсем так. Фигурально выражаясь, они пытаются усадить Вас за BMW с тем чтобы Вы могли сравнить ее с ВАЗ-ом, но Вы отказываетесь, аппелируя тем, что у BMW больше расход и что надо просто уметь ездить на ВАЗ-е.

PD>Сравнение некорректно. Если уж сравнивать, то надо сравнивать BMW с неким автомобилем, который хорошая фирма могла бы сделать ручной сборкой, а не на конвейере, и с деталями, сделаннными специально для этого автомобиля, а не отштапованными. Иными словами, сравнить BMW с неким гоночным автомобилем. Это и будет вполне подходящее сравнение — BMW штука хорошая, но выжать из двигателя внутреннего сгорания и прочего то, что они могут сейчас дать, он и близко не может.

Я сравнивал не для того, чтобы провести аналогию с технологиями. Я сравивал для того, чтобы дать Вам понять, чего же от Вас хотят оппоненты — что бы Вы попробовали (а уж ВАЗ и BMW или BMW и F1 — не важно).
И попробовать лучше пройти один и тот же путь разными способами. Путь, который упирается в Win32 не лучший в данном сравнении.

Здравствуйте, Aen Sidhe, Вы писали:

PD>>А кстати, такой вопрос. Ты утверждаешь 90:10. Я точных цифр не знаю, но пусть так. Но если из этих 90% исключить все приложения для www, которые никто никогда ни на асме, ни на С++ не предлагал писать , каково будет отношение между тем, что останется от этих 90% и тем, что сейчас входит в 10% ?

AS>Однако, с чего вдруг, мы будем убирать www приложения? Новые технологии спокойно позволяют писать такие приложения с использованием тех же средств, что и для десктопных приложений. Более того, я лично видел несколько отлично работающих сайтов на С++ (ActiveX, COM, etc).

Да, есть, точнее, осталось от прошлых лет. Если специально поискать, то можно, наверное и CGI на C++ найти. Но это несерьехно.

Вот поэтому я и предложил их отложить в сторону и сравнить. В области www — я вам сразу первенство отдаю и ни на что не претендую. Давай остальное сравним.

AS>Только вот проблема. Сменилось железо и всё переписывать? Ну удачи, я такого пути не понимаю.

Не все. Конечно, при переходе 486 -> Pentium или P3->P4 кое-что меняется. Но отнюдь не полное переписывание.
А на С++ вообще не надо переписывать. Перекомпилировать надо, да.

AS>Вот только, есть мнение, память и процессор новые дешевле месяца твоей работы. Не так ли? Это раз.

Да. Только вот одна проблема — именно моя текущая работа требует выжать из этого железа максимум того, что можно. Не выжму — цена месяца моей работы будет равна 0. И что делать ?

>Два, N и M уже сейчас стремятся к 1, если использовать нормальные алгоритмы и архитектуры.

Вот тебе пример. Делал как-то приложение на C#. Ничего особенного, форма с табами, на них всякие листбоксы и т.д. За сценой никаких больших объектов (потом при работе они появятся, но до первого запроса их нет). 17 Мб вся эта прелесть занимает. Уверен, что больше 4-5 Мб она занимать не должна — на MFC. На чистом Win API — думаю, в 2-3 Мб уложился бы, но на это точно много моего времени уйдет.

Ну а насчет скорости — тут меня лучше не трогай, я именно этим сейчас и занимаюсь. И если меня лишить прямого доступа к памяти (указателей, выравнивания, иными словами) — все , что я сделал — коту под хвост. А так — уже в 6 раз быстрее.


AS>Я не видел ни одной задачи, где требовалось переписывать алгоритм на асме.

Не могу тебе про нее рассказать, но именно это мне и предстоит. Правда, без явного __asm я все же обйдусь — есть intrinsic в C++. Проще говоря — SSE2

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

Поверь, она так обоснована экономически, как немногие другие задачи


>А просто сделать выполнение какой-нибудь большой операции, запускаемой раз в год в два раза быстрее — трата денег, причём напрасная.

А если эта задача выполняется на сотнях компьютеров 24 часа в сутки каждый день ?

>Я не спорю, что такие задачи есть. Но они точно попадут в исключения из правил.

Ну пусть будет исключение.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Здравствуйте, Aen Sidhe, Вы писали:

AS>>Только вот проблема. Сменилось железо и всё переписывать? Ну удачи, я такого пути не понимаю.

PD>Не все. Конечно, при переходе 486 -> Pentium или P3->P4 кое-что меняется. Но отнюдь не полное переписывание.
PD>А на С++ вообще не надо переписывать. Перекомпилировать надо, да.

64 битные платформы не забываем. Хотя, если указатели к интам не приводить, проблем, по идее не будет.
>>Два, N и M уже сейчас стремятся к 1, если использовать нормальные алгоритмы и архитектуры.

PD>Вот тебе пример. Делал как-то приложение на C#. Ничего особенного, форма с табами, на них всякие листбоксы и т.д. За сценой никаких больших объектов (потом при работе они появятся, но до первого запроса их нет). 17 Мб вся эта прелесть занимает. Уверен, что больше 4-5 Мб она занимать не должна — на MFC. На чистом Win API — думаю, в 2-3 Мб уложился бы, но на это точно много моего времени уйдет.

А есть разница для GUI приложения между 17 и 4 МБ? Сейчас браузеры по 100 отжирают и живём как-то.

PD>Ну а насчет скорости — тут меня лучше не трогай, я именно этим сейчас и занимаюсь. И если меня лишить прямого доступа к памяти (указателей, выравнивания, иными словами) — все , что я сделал — коту под хвост. А так — уже в 6 раз быстрее.

Ну, я вообще-то знаю, что такое прямой доступ к памяти, да. С С++ начинал в своё время

>>А просто сделать выполнение какой-нибудь большой операции, запускаемой раз в год в два раза быстрее — трата денег, причём напрасная.

PD>А если эта задача выполняется на сотнях компьютеров 24 часа в сутки каждый день ?

Значит, мы что-то делаем не так, имхо, если при этом забиты все ресурсы этих компов под 100% при этом. Хотя какое-нибудь сложное моделирование, которое заставит нас перебрать триллионы вариантов, или учитывающее пару десятков тысяч факторов — да, возможно. Но это всё же такая редкость, что я даже и не знаю.

Здравствуйте, samius, Вы писали:
S>Мне все же кажется, что это не так. Оппоненты пытаются донести что использование высокоуровневых средств более эффективно в большинстве задач, если речь идет не о железе. Эффективно — значит при схожей или чуть меньшей производительности решения оно будет дешевле и быстрее по срокам.
Это не так. Если бы мы хотели доказать именно это, то мечта Павла вполне бы сбылась.
Просто он подменяет понятия: сначала делает некое абстрактно-теоретическое утверждение, которое не может доказать. Все опровержения этого абстрактно-теоретического утверждения он последовательно игнорирует, пытаясь сделать вид, что его кто-то заставляет писать на C#.

На всякий случай напомню, что про шарп речь вообще не шла. Никто даже не пытается убедить Павла попробовать шарп (ну, кроме тебя). Речь шла о том, что Павел посмеялся над утверждением Игоря про способность ФП в теории получать более эффективный код, чем ассемблер. Вот и весь хрен до копейки.

А как только мы отстаем от этого абстрактно-теоретического рассуждения про сферические компиляторы в вакууме, сразу начинается суровая реальность. Со слабо проработанными оптимизаторами в реальных JIT, с отсутствием production quality оптимизаторов для ФП-языков и так далее.

В итоге, действительно, шкала ровно такая: максимальная производительность реального рантайм кода лежит в области максимальных же затрат на ручную оптимизацию.
Весь вопрос только в том, где проходит граница допустимых расходов на оптимизацию, и где проходит граница допустимой неэффективности.
Вот Павел приводит пример задачи, где нужно выжать 200мс вместо 15с. Я с легкостью поверю, что никакой компилятор сейчас не даст этого результата автоматически: те, у кого хорошие теоретические способности, не оборудованы бэкендами с поддержкой SSE и прочих хардкорных фич. А те, у кого хороший бэкенд, компилируют с таких языков, где нет возможности проводить хитрые оптимизации автоматом. Вот Павел и занимается ручным выравниванием структур и выпиливанием по интринсикам.

А вот у компании Ericsson был пример другой задачи, когда C++ оказался тупо непригоден потому, что стоимость разработки и отладки софта на нём превысила доступный бюджет. В итоге его выкинули и заменили самым медленным из промышленных ФП-языков; при этом, естественно, микропроизводительность упала со страшной силой. Но свитч заработал, и его надежность компенсирует все претензии к его производительности. Это — правое плечо графика.

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

Здравствуйте, Pavel Dvorkin, Вы писали:

AS>>Только вот проблема. Сменилось железо и всё переписывать? Ну удачи, я такого пути не понимаю.
PD>Не все. Конечно, при переходе 486 -> Pentium или P3->P4 кое-что меняется. Но отнюдь не полное переписывание.
PD>А на С++ вообще не надо переписывать. Перекомпилировать надо, да.
На .NET тоже не надо

AS>>Вот только, есть мнение, память и процессор новые дешевле месяца твоей работы. Не так ли? Это раз.
PD>Да. Только вот одна проблема — именно моя текущая работа требует выжать из этого железа максимум того, что можно. Не выжму — цена месяца моей работы будет равна 0. И что делать ?
Я выше приводил тест, где не напрягаясь мой код на C# выжимает из железа больше, чем ваш на C.

PD>Вот тебе пример. Делал как-то приложение на C#. Ничего особенного, форма с табами, на них всякие листбоксы и т.д. За сценой никаких больших объектов (потом при работе они появятся, но до первого запроса их нет). 17 Мб вся эта прелесть занимает. Уверен, что больше 4-5 Мб она занимать не должна — на MFC. На чистом Win API — думаю, в 2-3 Мб уложился бы, но на это точно много моего времени уйдет.
Пусть лучше прога занимает больше памяти, но работает быстрее. Мне десяток мегов оперативки сейчас вообще не жалко.

PD>Ну а насчет скорости — тут меня лучше не трогай, я именно этим сейчас и занимаюсь. И если меня лишить прямого доступа к памяти (указателей, выравнивания, иными словами) — все , что я сделал — коту под хвост. А так — уже в 6 раз быстрее.
И вы наверное предпочитаете руками реализовывать файловое хранилище, вместо использования БД...


>>А просто сделать выполнение какой-нибудь большой операции, запускаемой раз в год в два раза быстрее — трата денег, причём напрасная.
PD>А если эта задача выполняется на сотнях компьютеров 24 часа в сутки каждый день ?
>>Я не спорю, что такие задачи есть. Но они точно попадут в исключения из правил.
PD>Ну пусть будет исключение.
Для таких задач редко приходится сталкиваться с низкоуровневневой оптимизацией. Обычно производительность упирается в передачу данных.

Здравствуйте, Воронков Василий, Вы писали:

ВВ>Ну давай все-таки конкретнее говорить. Ты какой-то конкретный "суперкомплятор" имеешь в виду?
Суперкомпилятор это вполне конкретный давно усоявшейся термин. Появившейся еще в 70какомто году.

ВВ>Мало того, что такая "хардкорная" оптимизация возможна даже теоретически далеко не всегда, так в для языков на .NET ее ведь все равно никто не делает.
Если теоритичсеки возможно отследить зависимости суперкомпилятор сделает это всегда.

Здравствуйте, VoidEx, Вы писали:

WH>>Скажи это суперкомпиляторам...
VE>С каких пор суперкомпилятор стал уровнем абстракции?
Ты вобще читаешь то на что отвечаешь?

Здравствуйте, Sinclair, Вы писали:

S>На всякий случай напомню, что про шарп речь вообще не шла. Никто даже не пытается убедить Павла попробовать шарп (ну, кроме тебя).
Я про шарп ни слова не написал ))) это Павел.
А я подразумевал ту задачу с процентами.

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, VoidEx, Вы писали:

WH>>>Скажи это суперкомпиляторам...
VE>>С каких пор суперкомпилятор стал уровнем абстракции?
WH>Ты вобще читаешь то на что отвечаешь?
И как же так суперконпелятор оптимизирует, зная только о самом верхнем уровне абстракции?
Или таки он знает не только о верхнем?

Здравствуйте, Aen Sidhe, Вы писали:

AS>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>Здравствуйте, Aen Sidhe, Вы писали:

AS>>>Только вот проблема. Сменилось железо и всё переписывать? Ну удачи, я такого пути не понимаю.

PD>>Не все. Конечно, при переходе 486 -> Pentium или P3->P4 кое-что меняется. Но отнюдь не полное переписывание.
PD>>А на С++ вообще не надо переписывать. Перекомпилировать надо, да.

AS>64 битные платформы не забываем. Хотя, если указатели к интам не приводить, проблем, по идее не будет.

Не забываем, ох, не забываем

PD>>Вот тебе пример. Делал как-то приложение на C#. Ничего особенного, форма с табами, на них всякие листбоксы и т.д. За сценой никаких больших объектов (потом при работе они появятся, но до первого запроса их нет). 17 Мб вся эта прелесть занимает. Уверен, что больше 4-5 Мб она занимать не должна — на MFC. На чистом Win API — думаю, в 2-3 Мб уложился бы, но на это точно много моего времени уйдет.

AS>А есть разница для GUI приложения между 17 и 4 МБ? Сейчас браузеры по 100 отжирают и живём как-то.

Вот именно — как-то. Я совершенно убежден, что нынешнее ПО могло бы работать со скоростью раза в 3-4 больше и памяти кушать меньше. А пока что оно все тормозит, тормозит, тормозит и память ест, есть, ест. Отнюдь не только ПО под C#.

>>>А просто сделать выполнение какой-нибудь большой операции, запускаемой раз в год в два раза быстрее — трата денег, причём напрасная.

PD>>А если эта задача выполняется на сотнях компьютеров 24 часа в сутки каждый день ?

AS>Значит, мы что-то делаем не так, имхо, если при этом забиты все ресурсы этих компов под 100% при этом.

Все так. Просто есть такие задачи. Обработка огромных массивов данных при том, что эти данные поступают в реальном масштабе времени и отвечать нужно тоже в реальном масштабе. Я же говорил не раз — у нас разные совсем задачи.

Здравствуйте, WolfHound, Вы писали:

ВВ>>Ну давай все-таки конкретнее говорить. Ты какой-то конкретный "суперкомплятор" имеешь в виду?
WH>Суперкомпилятор это вполне конкретный давно усоявшейся термин. Появившейся еще в 70какомто году.

Это как-нибудь применимо, скажем, к C#?

ВВ>>Мало того, что такая "хардкорная" оптимизация возможна даже теоретически далеко не всегда, так в для языков на .NET ее ведь все равно никто не делает.
WH>Если теоритичсеки возможно отследить зависимости суперкомпилятор сделает это всегда.

Можно ссылку на суперкомпилятор для C#? Честно, не вижу много смысла муссировать рассуждения типа "теоретически возможно написать такой компилятор, который заоптимизирует все насмерть". Когда напишут — тогда и поговорим. А пока все абстракции — реализуемые средствами языков на .NET — о которых здесь и речь неизбежно несут оверхед.