Здравствуйте, jazzer, Вы писали:
J>Тот же питон — дичайшее тормозилово, но его можно (сюрприз!) использовать в научных вычислениях, потому что есть нативные библиотеки, написанные на Си, которые делают все быстро (NumPy、SciPy), а скриптовый язык просто предоставляет клей, которому нафиг не нужно быть супербыстрым и уж тем более компилиться в машкод.
Все это очень правильно и красиво пока не дошло дело до суровой реальности, в которой из-за нехватки или неадекватности существующих нативных библиотек, или из-за стремления все сделать самому, на тормозных скриптах пишется большая часть логики с соответствующим результатом.
Взять тот же php, штатные библиотеки иногда настолько неадекватны, что даже CRC приходилось считать скриптом.
LF>Меня иногда спрашивают о том, почему мы выбрали именно эту стратегию; почему компилятор C# не может напрямую генерировать машинный код без дополнительного промежуточного этапа? Зачем нам нужны два компилятора для преобразования кода на языке C# в машинные инструкции, когда достаточно было бы одного?
LF>Существует несколько причин, но все они более или менее сводятся к одному: в нашем случае система, построенная на основе промежуточного языка, существенно дешевле.
По ссылке объяснено, почему используется промежуточный язык, т.е. C# -> IL -> Native вместо C# -> Native.
А вопрос был про рантайм-исполнение промежуточного кода вместо нейтив.
Здравствуйте, midl, Вы писали:
M>Точней голых указателей. Умные могут быть. Причем даже не проблема в плюсах сделать менеджер памяти такой как в шарпе : с моментальным выделением памяти и отсутствием фрагментации. Но тогда и при удаленее он будет временами надолго подтупливать запуская сборку мусора.
А тут в принципе никуда не денешься. память надо выделять и освобождать, если это не Фортран-77 и не GW-Basic . Выделять всегда надо, когда требуется (есть хитрости, но о них не будем), а вот освобождать можно либо сразу, когда стал ненужен, либо периодически всех, которые стали не нужны после прошлого удаления. Поэтому в С++ нет таких тормозов, там удаляется более или менее равномерно по времени, а в системах со сборкой мусора есть. Ну и еще учти, что при удалении в С++ никто ничего не дефрагментирует, так как нельзя. А на дефрагментацию тоже время требуется. Зато да, в С++ нужно врем на выделение, так как поиск свободного блока и его расщепление. И фрагментация там тоже, да, хотя и не фатально это.
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, TimurSPB, Вы писали:
TSP>>В теории красиво и правильно. Согласен полностью. TSP>>Но вот от стыковки C# с C++ я удовольствие испытал весьма сомнительное.
J>За шарп не скажу, но сам я недавно сопрягал С++ с Питоном (а лет 15 назад — с Tcl), особых проблем не заметил, кроме детских проблем самого питона (многопоточность — это смерть, лучше ею не пользоваться в питоне вообще) + его специфические вещи типа счетчиков ссылок. J>Но тут, конечно, Boost.Python сильно выручает, с ним очень приятно все программить.
Хз-хз. У меня был негативный опыт года 3 назад. Кроме Буста ещё SWIG пробовал. Всё равно геморроя куча. Я вообще нормальный интероп видел только в связке Assembler->C->C++. В остальных случаях игра не стоит свеч.
M>В нативных Segmentation fault получить. Заметно проще, учитывая наличие почти во всех них Null Pointer'а. Есть исключения вроде Eiffel если не ошибаюсь, но они нафиг никому не нужны. В явах NPE получить тоже не проблема, но там хотя бы красивая трассировка стека будет вместо всяких "память не может быть read"
В явах/шарпах еще, что очень важно, при почти любой ошибке максимум свалится текущий поток, а не все приложение. Если потоки практически независимы(а это именно так в подавляющем большинстве веб-приложений), то другие треды просто не заметят падения собрата. В тех же плюсах непойманное исключение в любом потоке ложит весь сервер.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Pavel Dvorkin, Вы писали:
LVV>>2. Коды виртуальной машины можно обрабатывать как угодно — от чистой интерпретации до чистой компиляции в нативный код.
PD>И что ? Одно из двух : либо промежуточный язык будет достаточно близок к машинному, либо просядет скорость и существенно.
Хм. Насколько промежуточный жабовский язык поход на ассемблер х86? Практически никак. И тем не менее, в общем случае падение производительности не такое и большое. Плюс, JIT не стоит на месте, а очень даже развивается. А компилять код, зная контекст и аппаратное окружение, можно куда эффективнее, чем "для общего случая".
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Eugeny__, Вы писали:
E__>Хм. Насколько промежуточный жабовский язык поход на ассемблер х86? Практически никак. И тем не менее, в общем случае падение производительности не такое и большое.
Смотря на чем. Для матричных операций я получил 2-3 раза.
>Плюс, JIT не стоит на месте, а очень даже развивается. А компилять код, зная контекст и аппаратное окружение, можно куда эффективнее, чем "для общего случая".
Для обычного компилятора время не критично, и если проект компилируется минуты — переживем. JIT это себе позволить не может. Поэтому обычный компилятор может устроить какие угодно межмодульные оптимизации, в принципе его связка с линкером может перестраивать и оптимизировать код как угодно. JIT не может, по этой причине. Поэтому его развитие ограничено сложностью алгоритмов оптимизации — начиная с некоторой сложности, банально не хватит времени.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>До сих пор с тоской вспоминаю VS6 — она летала на тогдашних машинах, а эта тормозит на нынешних, и памяти жрет неимоверно больше. А возможностей (для С++) добавилось хорошо если процентов 50.
А ты запускал VC6 на Pentium-100 с 16M оперативы? Особенно после Developer Studio 4.0 (5-ю я пропустил). Шестерка, по ощущениям, тормозила неслабо по сравнению с четверкой. А сейчас, на DualCore c 2Г, летает, а 2010 — тормозит.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>У меня другое не получилось. Строки в Фортране
PD>CHARACTER S(100)
PD>и в скобках константа. А я очень хотел размер вычислять, и мог — в C-части, но вот вернуть обратно в Фортран не мог. Пришлось по максимуму заказать.
ЕМНИП, и нельзя было это сделать. Фортран длины строк во время выполнения не вычислял, а просто возвращал то, что указывалось при объявлении. Деталей уже не помню.
Непонятно только, а на фига тебе надо было строки в Фортран возвращать, он же не заточен на работу со строками. Точнее, там кое-что можно было сделать, но, по-моему, со строкой удобнее было работать как со скалярной переменной, в не массивом символов. Разумеется, в Фортране-77, в Ф4 существовали, ЕМНИП, только строковые константы.
Здравствуйте, Mazay, Вы писали:
J>>За шарп не скажу, но сам я недавно сопрягал С++ с Питоном (а лет 15 назад — с Tcl), особых проблем не заметил, кроме детских проблем самого питона (многопоточность — это смерть, лучше ею не пользоваться в питоне вообще) + его специфические вещи типа счетчиков ссылок. J>>Но тут, конечно, Boost.Python сильно выручает, с ним очень приятно все программить.
M>Хз-хз. У меня был негативный опыт года 3 назад. Кроме Буста ещё SWIG пробовал. Всё равно геморроя куча.
Я тоже пробовал и SWIG, и буст. К свигу я больше на пушечный выстрел не подойду. А с бустом я особых проблем не испытывал.
M>Я вообще нормальный интероп видел только в связке Assembler->C->C++.
Ну, это интеропом сложно назвать
M>В остальных случаях игра не стоит свеч.
Ну здрасте. Типа не стоит свеч скриптование программы, лучше перекомпилировать на каждый чих, чем менять скрипты?
Посмотри на те же игры, в них же без скриптов никуда.
Плюс очень удобно питоном (и любыми другими скриптами, тем же VBA) тестировать свои компоненты в стиле "а если так?" — скорость тестирования на пару порядков возрастает по сравнению с написанием юнит-теста, требующим перекомпиляции на каждое плёвое изменение.
Здравствуйте, quwy, Вы писали:
Q>Здравствуйте, jazzer, Вы писали:
J>>Тот же питон — дичайшее тормозилово, но его можно (сюрприз!) использовать в научных вычислениях, потому что есть нативные библиотеки, написанные на Си, которые делают все быстро (NumPy、SciPy), а скриптовый язык просто предоставляет клей, которому нафиг не нужно быть супербыстрым и уж тем более компилиться в машкод. Q>Все это очень правильно и красиво пока не дошло дело до суровой реальности, в которой из-за нехватки или неадекватности существующих нативных библиотек, или из-за стремления все сделать самому, на тормозных скриптах пишется большая часть логики с соответствующим результатом.
Ну так я о том и говорю, что нужны быстрые нативные компоненты, типа того же NumPy и SciPy. Не было бы их — мы бы пользовались питоном сильно меньше, а то и перешли бы на другой скриптовый язык (Луа, например), ибо в Питоне уж очень много несуразностей.
Q>Взять тот же php, штатные библиотеки иногда настолько неадекватны, что даже CRC приходилось считать скриптом.
Ну так а кто мешает самому написать CRC на плюсах и юзать из php?
Но вообще ты правильную проблему озвучиваешь. Я много раз видел, когда человек добавляет скриптование для своей нативной подсистемы (небольшое и к месту), и оно всем настолько нравится, что этот скрипт начинает использоваться не по назначению, далеко за пределами, предполагаемыми изначально автором, и через пару-тройку лет все превращается в помойку (потому что, к примеру, нет в помине модульности, ибо какая нафиг модульность для однострочных (изначально) скриптов), а в результате все ругают автора скрипта, типа говноязык соорудил.
Но это социальная проблема, не зависящая от конкретного скриптового языка.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Ничего нового не произошло. То же самое было 10 и 20 и 30 лет назад. И тогда были программисты, которые писали на Фортране и С/C++, и программисты, которые писали на Бейсике. И вторых всегда было больше, чем первых. PD>ПО, которое продается в тысячах и миллионах копий, как писали на нативных языках, так и пишут. ПО, которое делается на заказ, как писали раньше на Бейсике, так и пишут сейчас на его духовных наследниках.
Да нет. Изменилось. ПО, распространяемое миллиардами копий, написано на html и прочих javascipt'ах. Добро пожаловать в интернет.
Здравствуйте, andyJB, Вы писали:
JB>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Ничего нового не произошло. То же самое было 10 и 20 и 30 лет назад. И тогда были программисты, которые писали на Фортране и С/C++, и программисты, которые писали на Бейсике. И вторых всегда было больше, чем первых. PD>>ПО, которое продается в тысячах и миллионах копий, как писали на нативных языках, так и пишут. ПО, которое делается на заказ, как писали раньше на Бейсике, так и пишут сейчас на его духовных наследниках. JB>Да нет. Изменилось. ПО, распространяемое миллиардами копий, написано на html и прочих javascipt'ах. Добро пожаловать в интернет.
А ведь правда... Гмыло теперь у миллиардов, и уже не скажешь, что это просто сайт — это приложение. На 100 мегабитах инета и хорошем проце оно грузится быстрее локального клиента с диска(или то у меня тормозной жесткий — хз, но инет точно быстрее, тем более, что местный вообще гигабит, а там возможны флюктуации до 300-400 мегабит с мира засчет хитрой загрузки через ua-ix, этого в тарифах нет, но в реале бывает). Особенно это видно на документах — офис(хоть опен под лин, хоть мс под вин) тупо дольше загружает нативу, чем открывание документа онлайн — оно моментальное, а приложение пока загрузится, несколько секунд! Да, у оффлайна больше фич, но в 99% они мне не упились — мне просмотреть в основном надо, ну да чутка поменять. Я уже не говорю про совместную обработку.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, TimurSPB, Вы писали:
F>>Такой принцип уже применили к промышленности, и теперь практически всё делается в Китае. TSP>И что? Ну стоила бы вся техника в 5 раз дороже без Китая.
А может быть, просто у кого-то бонусы были бы раз в 50 меньше. Кто знает?
Здравствуйте, LuciferSingapore, Вы писали:
LS>Здравствуйте, Mazay, Вы писали:
LS>Нет, ты не понял. Просто управляемые языки пока еще не настолько совершенны, чтобы упереться в ограничения железа и ОС. LS>Когда-нибудь, возможно, они подтянутся к этому уровню, но пока — увы и ах.
что за ерунда. питон интерпретируемый? байт-код говорите? это у вас байт-код, а я юзаю транслятор питона в си, а си компилируется в машинный код. скорость существенно возрастает.
язык не знает о том какой он -- нативный или нет. можно написать интерпретатор си (правда непонятно зачем), а можно компилятор bat файлов. кстати, компилятор bat файлов во времена ms-dos существовал и пользовался популярностью (скорость возрастала в разы).
популярность управляемых языков (блин, какой неправильный термин) вызвана легкостью создания трансляторов. все прелести управляемых сред можно реализовать и в нативном коде. причем, более эффективно. например, если глобальный оптимизатор видит, что функция foo обращается к строкам по индексу _гарантированно_ не выходя за их границы, то проверки на этапе компиляции достаточно. если мы складываем a и b и язык гарантирует выброс исключения при переполнении, то компилятор опять-таки может прикинуть где переполнения гарантированно не будет, а где не избежать проверки в рантайме. а вот транслятор в байт-код будет тупить. т.к. исключение выбрасывает виртуальная машина при сложении и проверяет на переполнение при каждом вызове.
с другой стороны, упомянутый компилятор питона в си не поддерживает некоторых фич функционального программирования. ибо компилятору их реализовать намного сложнее, чем интерпретатору.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, Privalov, Вы писали:
P>ЕМНИП, и нельзя было это сделать.
Ну да. А хотелось.
P>Непонятно только, а на фига тебе надо было строки в Фортран возвращать, он же не заточен на работу со строками. Точнее, там кое-что можно было сделать, но, по-моему, со строкой удобнее было работать как со скалярной переменной, в не массивом символов. Разумеется, в Фортране-77, в Ф4 существовали, ЕМНИП, только строковые константы.
Просто надо было создать Фортран-интерфейс к С-коду, то есть вызывать все С-функции из фортрана. А одна из функций какую-то строку возвращала.
Здравствуйте, andyJB, Вы писали:
JB>Да нет. Изменилось. ПО, распространяемое миллиардами копий, написано на html и прочих javascipt'ах. Добро пожаловать в интернет.
Спасибо за приглашение . Остается подождать, когда это ПО будет по функциональности обеспечивать хотя бы 20% от того, что делают серьезные пакеты , написанные на нативном коде. Когда появится нечто похожее на Фотошоп, Автокад, Ворд и т.д. Вот тогда я готов буду принять, что подобное ПО можно писать не на нативных языках.
. Выделять всегда надо, когда требуется (есть хитрости, но о них не будем), а вот освобождать можно либо сразу, когда стал ненужен, либо периодически всех, которые стали не нужны после прошлого удаления. Поэтому в С++ нет таких тормозов, там удаляется более или менее равномерно по времени, а в системах со сборкой мусора есть. Ну и еще учти, что при удалении в С++ никто ничего не дефрагментирует, так как нельзя. А на дефрагментацию тоже время требуется. Зато да, в С++ нужно врем на выделение, так как поиск свободного блока и его расщепление. И фрагментация там тоже, да, хотя и не фатально это.
.jpg)
