Comments 78
Так если они созданы для того чтобы не думать о индексах в массиве и кодировке строк, зачем наворачивать ненужные сложности? Надо скорость — спустись ниже, надо удобство — делай прозрачно. Все-таки не ракеты на питоне работают, но и сайты на с++ как-то не пишут
Хорошо написано, легко и толково.
И намёк на Джоела в первом абзаце… верно я понимаю?
И намёк на Джоела в первом абзаце… верно я понимаю?
да, © Joel Spolsky Письмо о стратегии VI
UFO just landed and posted this here
А за что плюсовать?
Статью минусуют те, кто знает, что такое компилятор и интерпретатор. И кому не нравится ламеризм и тупость.
Если так, то странно, ибо в самом начале написано для кого предназначена статья…
Да нет, уж лучше им такого не читать, плодить говнокодеров «не есть гуд», уж лучше пусть новички достоверные источники почитают, а не «это». (Ничего личного, просто материал не соответствует действительности не менее чем полностью.)
Суть материала выражены в выделенном жирным и заголовке. Краткое описание видов языков — всего лишь абстрактное описание работы, чтобы человек не ведующий, понимал из какой темы материал ему следует почитать при возникновении каких-либо вопросов.
Согласитесь, что многие новечки, без знания компилируемых языков, даже не задумываются о том, что тут выделено. А гуру, комментирующие эту статью, дают советы только из области алгоритмов. В то время как подчеркнутое тут — это фундамент. QuickSort не будет столь быстр, если его написать не по учебнику, а как в голову прийдет.
А большинство комментаторов почему-то решили что здесь должно быть точное академическое разжевывание конкретных языков программирования или сравнения производительности. Для этого, как раз, есть учебники и интернет.
Согласитесь, что многие новечки, без знания компилируемых языков, даже не задумываются о том, что тут выделено. А гуру, комментирующие эту статью, дают советы только из области алгоритмов. В то время как подчеркнутое тут — это фундамент. QuickSort не будет столь быстр, если его написать не по учебнику, а как в голову прийдет.
А большинство комментаторов почему-то решили что здесь должно быть точное академическое разжевывание конкретных языков программирования или сравнения производительности. Для этого, как раз, есть учебники и интернет.
Да прекратите вы бредить!
То, что вы описываете, это ламерская чушь, а не «фундамент». Это просто откровенная и стопроцентная ложь. Не «неточности», а грязная ложь и отвратительная чушь. Вы ничего не знаете про узкие места того, что вы так по идиотски обозвали «интерпретаторами», и от ваших вредных глупых советов новички только запутаются.
То, что вы описываете, это ламерская чушь, а не «фундамент». Это просто откровенная и стопроцентная ложь. Не «неточности», а грязная ложь и отвратительная чушь. Вы ничего не знаете про узкие места того, что вы так по идиотски обозвали «интерпретаторами», и от ваших вредных глупых советов новички только запутаются.
а поконкретнее, по пунктам для самообразования? если я на столько не прав.
Да хотя бы этот глупейший, ужасающий бред про строки и UTF-8. Вы вообще в курсе, что в Java и .NET внутри UTF-16? Соответственно, оно и работает в большинстве случаев быстрее чем 8-битное ASCII-представление (за счет выравнивания). Бред про более медленный поиск вообще смешон.
Это если оставить в стороне бредовость самой постановки вопроса. Что мол «интерпретируемые» (в вашей ламерючьей терминологии) языки неизбежно существенно медленнее того, что вы так же ламерски назвали «компилируемыми».
Это если оставить в стороне бредовость самой постановки вопроса. Что мол «интерпретируемые» (в вашей ламерючьей терминологии) языки неизбежно существенно медленнее того, что вы так же ламерски назвали «компилируемыми».
а почему в качестве примера взята только Java и .NET? Я описывал интерпретируемые языки в целом, а не какой-то конкретный язык. Кроме Java есть еще те же PHP, Javascript, Basic,… В них всех тоже UTF-16? Вы же привели частный случай, о котором читатель может узнать сам.
Про поиск я тоже не соглашусь, потому как да, медленнее производить поиск N-ного символа в строке, ширина 1 символа которой может меняться.
Вот по поводу скорости выполнения интерпретируемых языков я частично соглашусь. Да, варианты где компиляция происходит в момент запуска приложения могут выполняться быстрее (и то с условием что противник не достаточно оптимизирован). Но если учитывать общую скорость, включая скорость холодного старта, то не совсем…
Про поиск я тоже не соглашусь, потому как да, медленнее производить поиск N-ного символа в строке, ширина 1 символа которой может меняться.
Вот по поводу скорости выполнения интерпретируемых языков я частично соглашусь. Да, варианты где компиляция происходит в момент запуска приложения могут выполняться быстрее (и то с условием что противник не достаточно оптимизирован). Но если учитывать общую скорость, включая скорость холодного старта, то не совсем…
Ну, во первых, прекратите пороть чушь, что Java и .NET «интерпретируемые». Во вторых, раз вы их в эту категорию записали, то и бред про строки к ним тоже относится. Собственно, очень мало какие языки используют UTF-8 в качестве внутреннего представления. Go, разве что. Чисто компилируемый в нейтив, между прочим. В Javascript тоже UTF-16, в Visual Basic ровно то же что и в C#, про PHP не знаю, там по моему вообще всё плохо. Я привел не частный случай, а наиболее общий.
Про поиск — не надо бредить. Во первых, конкретно для поиска абсолютно наплевать, какого размера каждый отдельный символ, вы просто не имеете ни малейшего представления о том, как работают регулярные выражения. Во вторых, в UTF-16 все символы одинакового размера.
Про «общую скорость» же посоветую тоже не бредить.
В общем, учитесь. Вы от вашей заявленной «целевой аудитории» начинающих отличаетесь в худшую сторону. Вы точно так же абсолютно ни хрена не знаете, но сами считаете, что что-то знаете и что можете этим неверным и глупым «знанием» делиться с другими. Они — чайники, а вот вы уже ламер.
Про поиск — не надо бредить. Во первых, конкретно для поиска абсолютно наплевать, какого размера каждый отдельный символ, вы просто не имеете ни малейшего представления о том, как работают регулярные выражения. Во вторых, в UTF-16 все символы одинакового размера.
Про «общую скорость» же посоветую тоже не бредить.
В общем, учитесь. Вы от вашей заявленной «целевой аудитории» начинающих отличаетесь в худшую сторону. Вы точно так же абсолютно ни хрена не знаете, но сами считаете, что что-то знаете и что можете этим неверным и глупым «знанием» делиться с другими. Они — чайники, а вот вы уже ламер.
про Javascript не знал, спасибо за информацию.
а я старался писать обобщенно, не опираясь только на сегодня. Потому критика с частными случаями, даже популярными сегодня, не уместна…
А вот с UTF-16 у вас пробел в знаниях:
© Wikipedia (http://en.wikipedia.org/wiki/UTF-16/UCS-2)
я всегда готов пояснить все всем, у кого возникли вопросы по поводу моей писанины. Могу согласиться лиш с тем, что я не писатель :) Это была моя первая проба пера.
Я привел не частный случай, а наиболее общий.
а я старался писать обобщенно, не опираясь только на сегодня. Потому критика с частными случаями, даже популярными сегодня, не уместна…
А вот с UTF-16 у вас пробел в знаниях:
In computing, UTF-16 is a variable-length character encoding for Unicode
© Wikipedia (http://en.wikipedia.org/wiki/UTF-16/UCS-2)
я всегда готов пояснить все всем, у кого возникли вопросы по поводу моей писанины. Могу согласиться лиш с тем, что я не писатель :) Это была моя первая проба пера.
Вы написали обобщенную безграмотную чухню.
Да, с UTF-16 ошибся, имел в виду именно UCS-2. В Java и в .NET все символы двухбайтовые во внутреннем представлении.
Но — даже для представлений с переменной длиной символа, на скорость поиска это никак не влияет. Так что абсолютно всё что вы написали является безграмотным бредом.
Да, с UTF-16 ошибся, имел в виду именно UCS-2. В Java и в .NET все символы двухбайтовые во внутреннем представлении.
Но — даже для представлений с переменной длиной символа, на скорость поиска это никак не влияет. Так что абсолютно всё что вы написали является безграмотным бредом.
на тему «Java — не интерпретируемый язык»: в какой-то степени вы правы и официальная точка зрения со мной не согласится, но я же написал: «Я бы их разбил на 3 группы (возможно, они так и разбиваются)». И далее идет мое описание этих групп.
Почему я отнес Java и подобные языки к интерпретируемым? Потому что они не генерят нативный код. Они генерят байт-код. А с байт-кодом можно вытворять что угодно: хочешь, интепретируй в реальном времени, хочешь, интерпретируй при запуске весь код за раз (компилируй), хочешь, интерпретируй по библиотечно. Т.е. их можно было бы выделить в отдельную группу, но это будет группа цепляющая интерпретаторы, так как отдельные их реализации будут чистыми интерпретаторами.
Я ни на что не претендую, если что. :) Если для вас понимание общих принципов — это доскональное, 100% по учебнику, описание одного-двух популярных нынче языков, значит мы с вами по разному смотрим на абстрактное :)
Почему я отнес Java и подобные языки к интерпретируемым? Потому что они не генерят нативный код. Они генерят байт-код. А с байт-кодом можно вытворять что угодно: хочешь, интепретируй в реальном времени, хочешь, интерпретируй при запуске весь код за раз (компилируй), хочешь, интерпретируй по библиотечно. Т.е. их можно было бы выделить в отдельную группу, но это будет группа цепляющая интерпретаторы, так как отдельные их реализации будут чистыми интерпретаторами.
Я ни на что не претендую, если что. :) Если для вас понимание общих принципов — это доскональное, 100% по учебнику, описание одного-двух популярных нынче языков, значит мы с вами по разному смотрим на абстрактное :)
Повторяю, ваше деление языков на «группы» вообще ламерское и нелепое, и не имеет никакого практического смысла, даже если забыть о том, насколько оно некорректно.
"Потому что они не генерят нативный код. Они генерят байт-код. А с байт-кодом можно вытворять что угодно: хочешь, интепретируй в реальном времени, хочешь, интерпретируй при запуске весь код за раз (компилируй), хочешь, интерпретируй по библиотечно."
Вы будете смеяться, но тот же Си компилируется через несколько виртуальных машин, многие из которых еще более далеки от «реального железа» чем несчастная JVM. На тот же GIMPLE в GCC посмотрите, хотя бы. И да, с ними можно делать что хочешь, хоть интерпретировать, хоть компилировать. Так что ваш критерий абсолютно нелеп, и проистекает он от вашей безграмотности и от незнания того, как устроены все современные компиляторы.
И повторюсь — вы не понимаете никаких общих принципов. Вообще. Ни на каком уровне. Вы хуже чем чайники. Вы ламер. Чайник просто не знает, а вы «знаете» какую-то вами выдуманную чушь, не имеющую отношения к реальности.
"Потому что они не генерят нативный код. Они генерят байт-код. А с байт-кодом можно вытворять что угодно: хочешь, интепретируй в реальном времени, хочешь, интерпретируй при запуске весь код за раз (компилируй), хочешь, интерпретируй по библиотечно."
Вы будете смеяться, но тот же Си компилируется через несколько виртуальных машин, многие из которых еще более далеки от «реального железа» чем несчастная JVM. На тот же GIMPLE в GCC посмотрите, хотя бы. И да, с ними можно делать что хочешь, хоть интерпретировать, хоть компилировать. Так что ваш критерий абсолютно нелеп, и проистекает он от вашей безграмотности и от незнания того, как устроены все современные компиляторы.
И повторюсь — вы не понимаете никаких общих принципов. Вообще. Ни на каком уровне. Вы хуже чем чайники. Вы ламер. Чайник просто не знает, а вы «знаете» какую-то вами выдуманную чушь, не имеющую отношения к реальности.
тот же Си компилируется через несколько виртуальных машин
но на выходе же он дает не промежуточные звенья для исполнения…
Вы похожи на студента, ворвавшегося в начальные классы с разоблачениями, 80% заявлений которого — пустые оскорбления. На любое мое объяснение вы уже смотрите через призму ЧСВ, выискивая частные случаи не совсем относящиеся к вопросу, но якобы доказывающую ваше утверждение…
Что вас до сих пор держит в этой ветке? :)
но на выходе же он дает не промежуточные звенья для исполнения…
Да ну? Тот же clang может вывести llvm-биткод, например.
Да и, собственно, какая разница?
Что вас до сих пор держит в этой ветке? :)
То, что я очень не люблю самоуверенных идиотов и ламеров. Вы, ни хрена не зная про языки программирования, беретесь их классифицировать (и пожалуйста, классифицируйте себе молча), и что гораздо хуже, рассказывать о своих бреднях начинающим.
До вас, неумного ламера, так и не дошло. Вы считаете, что доступным языком какие-то азы рассказываете, тогда как на самом деле вы пишете абсолютную, стопроцентную чушь. Ложь и идиотизм в каждом вашем утверждении. И что самое отвратительное, вместо того, чтобы признать это и исправиться вы имеете наглость упираться и отстаивать свою заведомо идиотскую точку зрения.
Да ну? Тот же clang может вывести llvm-биткод, например.
Да и, собственно, какая разница?
Что вас до сих пор держит в этой ветке? :)
То, что я очень не люблю самоуверенных идиотов и ламеров. Вы, ни хрена не зная про языки программирования, беретесь их классифицировать (и пожалуйста, классифицируйте себе молча), и что гораздо хуже, рассказывать о своих бреднях начинающим.
До вас, неумного ламера, так и не дошло. Вы считаете, что доступным языком какие-то азы рассказываете, тогда как на самом деле вы пишете абсолютную, стопроцентную чушь. Ложь и идиотизм в каждом вашем утверждении. И что самое отвратительное, вместо того, чтобы признать это и исправиться вы имеете наглость упираться и отстаивать свою заведомо идиотскую точку зрения.
ok, я так понимаю на любую мою, в данном случае, классификацию вы найдете пример опровергающий ее. Могу я у вас узнать, как бы вы классифицировали современные языки программирования, для начинающих программистов? :)
Не на любую классификацию, а на некорректную.
Одной общей классификации нет и быть не может, а вот по разным аспектам языки можно разделить на managed/unmanaged (по наличию GC), на скриптовые и нескриптовые (по наличию в языке eval, но некоторые считают критерием просто наличие REPL), на динамически и статически типизированные, на языки общего назначения и [e]DSL. Языки можно разделить по парадигмам, на императивные, декларативные и гибридные. И всё это будет очень грубой и приблизительной классификацией.
Пытаться эти классификации еще дальше огрубить и выдать это за классификацию для «начинающих» — просто глупо и нелепо. И, главное, совершенно неясен смысл. Вы хотите дать советы по увеличению производительности? Давайте. Только без совершенно не относящихся к этой теме классификаций. И основывайте ваши советы не на «наблюдении» и досужих домыслах, а на измерении.
Одной общей классификации нет и быть не может, а вот по разным аспектам языки можно разделить на managed/unmanaged (по наличию GC), на скриптовые и нескриптовые (по наличию в языке eval, но некоторые считают критерием просто наличие REPL), на динамически и статически типизированные, на языки общего назначения и [e]DSL. Языки можно разделить по парадигмам, на императивные, декларативные и гибридные. И всё это будет очень грубой и приблизительной классификацией.
Пытаться эти классификации еще дальше огрубить и выдать это за классификацию для «начинающих» — просто глупо и нелепо. И, главное, совершенно неясен смысл. Вы хотите дать советы по увеличению производительности? Давайте. Только без совершенно не относящихся к этой теме классификаций. И основывайте ваши советы не на «наблюдении» и досужих домыслах, а на измерении.
То есть вы считаете, что начинающих можно и нужно обманывать? Статья грамотного человека только посмешит, а вот начинающий может с дури и поверить. Так что статья откровенно вредная.
>> Его все еще необходимо переводить на язык ЦПУ. Поэтому очевидно, что слухи о Java, которая работает быстрее C++, заметно преувеличены. И это останется так, пока >> процессоры не научатся понимать байт-код Java.
Автор, вы слышали про JIT? Процессор исполняет откомпилированный код, которые мало отличается от того, что выдал бы компилятор c++ (ну, за исключением дополнительного кода, сгенерированного для поддержки рантайма).
Более того, C# и не предназначен для интерпретации — при запуске или при установке приложения в систему оно компилируется в машинный код целевого процессора. Никакого байт-кода, вы о чем вообще?
Попробуйте почитать какую-нть книжку, выпущенную после 1990-95го, например
Автор, вы слышали про JIT? Процессор исполняет откомпилированный код, которые мало отличается от того, что выдал бы компилятор c++ (ну, за исключением дополнительного кода, сгенерированного для поддержки рантайма).
Более того, C# и не предназначен для интерпретации — при запуске или при установке приложения в систему оно компилируется в машинный код целевого процессора. Никакого байт-кода, вы о чем вообще?
Попробуйте почитать какую-нть книжку, выпущенную после 1990-95го, например
Да не в том же дело. Знать тонкости работы ваших инструментов — это признак профи, вот в чём суть.
А когда главный аргумент: у меня и так работает — ну что тут можно сказать… промолчу.
А когда главный аргумент: у меня и так работает — ну что тут можно сказать… промолчу.
Тогда статью надо озаглавить по-другому, не находите?
Возможно, хотя и необязательно. Вы могли бы предложить свой вариант?
Из бесплатных вариантов: «Вопросы производительности в распространенных инструментах программирования».
Далее, вне зависимости от названия, статья должна быть раз в пять длиннее. Ибо всяко тема не раскрыта. А так — это полуночные записки, а не статья, разбавленная абзацем из конспекта по информатике 10-15тилетней давности
Далее, вне зависимости от названия, статья должна быть раз в пять длиннее. Ибо всяко тема не раскрыта. А так — это полуночные записки, а не статья, разбавленная абзацем из конспекта по информатике 10-15тилетней давности
Согласна. Но Вы знаете, иногда очень достаёт объяснять эти прописные истины на пальцах тем, у кого не было даже этих конспектов. Этакие гении без высшего образования или заочники, сдавшие все экзамены по сходной цене… И все такие гордые, что не смей их учить.
Хорошо бы ещё больше и посерьёзнее аргументов привести о том, почему это полезно знать. Может действительно стоило бы доработать эту статью, чтоб была не только идея, но и обоснование, и широкий обзор. Тема то хорошая.
Хорошо бы ещё больше и посерьёзнее аргументов привести о том, почему это полезно знать. Может действительно стоило бы доработать эту статью, чтоб была не только идея, но и обоснование, и широкий обзор. Тема то хорошая.
Интерпретаторы — эти языки представляют собой высшую ступень эволюции…
Это не просто пипец, это адский пипец.
Во-первых, интерпретаторы — это не языки.
Во-вторых многие языки могут как компилироваться так и интерпретироваться.
В-третих, как уже сказано, C# и Java по-умолчанию не интерпретируются, а JIT-компилируются.
В-четвёртых, какая нафиг ступень какой эволюции? Где грибы брали?
Не знаю как java, а C# вообще не умеет интерпретироваться :) даже по не умалчанию!
ви таки будете удивлены, но существует опенсорцный интерпретатор. и даже не один.
1. я старался суть передать, а не терминами забросать. Мне кажется для понимания это важнее.
2. опять же описывал общее положение вещей. Конкретику оставил на читателе. Если ему интересно, всегда есть возможность узнать подробности о необходимом языке. Обо всех языках все равно не напишешь в одной статье…
3. считай интерпретируются 1 раз. Т.е. запуск такого приложения будет более медленным, чем предварительно откомпилированное.
2. опять же описывал общее положение вещей. Конкретику оставил на читателе. Если ему интересно, всегда есть возможность узнать подробности о необходимом языке. Обо всех языках все равно не напишешь в одной статье…
3. считай интерпретируются 1 раз. Т.е. запуск такого приложения будет более медленным, чем предварительно откомпилированное.
я бы хотел отметить 3 темы, которые… могут дать существенный прирост производительности
Я, со своей стороны, хотел бы отметить пагубность преждевременной оптимизации. Don't assume — measure!
при чем тут преждевременная оптимизация?
Я вот что хотел сказать. С учётом вашей целевой аудитории (через 3 недели – мы уже пишем какой-то проект), думаю, можно с уверенностью утверждать, что в этом самом проекте очень и очень много других узких мест, гораздо более узких, чем работа со строками или «жирок» на классах используемого фреймворка.
Такое ощущение, что эту статью писал мой шестидесятилетний лектор по программированию.
Наконец-то добрались до Хабра, и решили всем рассказать, почему Паскаль лучше Java?! ?!!
Если уж Вы, глубокоуважаемый автор, решили открыть нам глаза на то, что происходит при выполнении команд языков высокого уровня — Вы облажались.
Чушь собачья, а не статья!
Наконец-то добрались до Хабра, и решили всем рассказать, почему Паскаль лучше Java?! ?!!
Если уж Вы, глубокоуважаемый автор, решили открыть нам глаза на то, что происходит при выполнении команд языков высокого уровня — Вы облажались.
Чушь собачья, а не статья!
Вы знаете, с таким подходом можно смело утверждать, что на C++ писать тоже нельзя — только на чистом C. А почему, спросите вы? А потому что при использовании C++ велик соблазн воспользоваться прелестями dynamic dispatch (в виде виртуальных методов). В таких случаях цепочка вызова методов не всегда может быть однозначно определена при компиляции, а это означает дополнительные проверки во время выполнения кода, т.е. определенный overhead присутствует.
Automated memory management и интерпретируемый код на самом деле представляют собой «замедление» такого же порядка. Нам всем почему долдонят в институтах, что в первую очередь быстродействие определяется алгоритмами, а уже потом всем остальным.
Твиттер долгое время крутился на сверхмедленном Руби, а переводить отдельные его компоненты стали только тогда, когда это потребовалось. Причем переходили не на C, а на Scala, который — о, ужас! — aж на чуть-чуть медленней Java: shootout.alioth.debian.org/u32/which-programming-languages-are-fastest.php?gpp=on&javasteady=on&scala=on&ghc=on&v8=on&vw=on&hipe=on&lua=on&python3=on&perl=on&php=on&ruby=on&calc=chart
Automated memory management и интерпретируемый код на самом деле представляют собой «замедление» такого же порядка. Нам всем почему долдонят в институтах, что в первую очередь быстродействие определяется алгоритмами, а уже потом всем остальным.
Твиттер долгое время крутился на сверхмедленном Руби, а переводить отдельные его компоненты стали только тогда, когда это потребовалось. Причем переходили не на C, а на Scala, который — о, ужас! — aж на чуть-чуть медленней Java: shootout.alioth.debian.org/u32/which-programming-languages-are-fastest.php?gpp=on&javasteady=on&scala=on&ghc=on&v8=on&vw=on&hipe=on&lua=on&python3=on&perl=on&php=on&ruby=on&calc=chart
Где вы прочли в статье призыв писать на каком-либо языке?
В ней лишь указаны узкие места о которых некоторые программисты не задумываются, либо не знают. И все.
В ней лишь указаны узкие места о которых некоторые программисты не задумываются, либо не знают. И все.
А вы эти якобы «узкие места» таки сами выдумали, или вам профайлер о них рассказал? Сдается мне, что первое.
Наблюдение за чужими разработками. В основном это Javascript и PHP.
По Java и .NET'у общие наблюдения работы программ и сравнение их с аналогами на C/C++.
не по теории, точно.
По Java и .NET'у общие наблюдения работы программ и сравнение их с аналогами на C/C++.
не по теории, точно.
Ах, «наблюдение». Не корректные измерения с помощью профайлера или хотя бы секундомера, а тупо «наблюдение». Так дела не делаются.
Повторяю для особо одаренных — все, что вы тут в «узкие места» записали, таковыми никоим образом не является. Ни в каком приближении.
Повторяю для особо одаренных — все, что вы тут в «узкие места» записали, таковыми никоим образом не является. Ни в каком приближении.
Когда разница заметна на глаз, секундомер не нужен.
«Излишняя уверенность — источник ошибки» ©
Ваши утверждения по поводу скорости получения подстрок в UTF-строках уже о многом сказали…
«Излишняя уверенность — источник ошибки» ©
Ваши утверждения по поводу скорости получения подстрок в UTF-строках уже о многом сказали…
Да, как я мог забыть — вы же несли отвратительную чушь про скорость поиска в UTF-строках. Извольте ка ответить, что вы имели в виду? Для регулярных выражений нет никакой разницы. Или вы random access считаете? Ну так запомните, нет общеупотребимых языков, где random access к элементу строки не был бы O(1). Хаскелль не считаем, там строки вообще в виде списков реализованы.
Много букв, а смысла нет.
Делить языки программирования на компиляторы и интерпретаторы — все равно, что человеческие языки делить на те, на которых говорят и те, на которых пишут. Бред. Компиляторы и интерпретаторы — это виды трансляторов. С одного языка может быть много разных трансляторов. С той же Java: gcj умеет компилировать Java-программу сразу в нативный код.
Очевидно лишь то, что Вы плохо разбираетесь в том, о чем пишете. Известно, что DAC (dynamic adaptive compiler, разновидность JIT), коим обладает JVM, способен порождать более оптимальный нативный код, нежели чем статический ahead-of-time компилятор для C++ или любого другого языка. Дело в том, что во время исполнения программы компилятору известно гораздо больше о платформе и о runtime окружении. Вот лишь некоторые из оптимизаций, недоступных C++ компиляторам, которые делает JVM в runtime: девиртуализация (замена виртуальных вызовов на статические), динамическая профиляция (ипользования информации о том, какие ветки исполняются чаще), использование архитектурных особенностей процессора, на котором в данный момент исполняется программа (SSE, NUMA и т.п.)
Короче говоря, прежде чем писать об интерпретаторах, изучите предмет. Говорить об интерпретации Javascript, PHP, Perl, Python, Java и даже не упомянуть о понятии виртуальной машины… На кого бы ни была рассчитана статья, она по меньшей мере просто бесполезна, и, более того, не соответствует действительности.
Делить языки программирования на компиляторы и интерпретаторы — все равно, что человеческие языки делить на те, на которых говорят и те, на которых пишут. Бред. Компиляторы и интерпретаторы — это виды трансляторов. С одного языка может быть много разных трансляторов. С той же Java: gcj умеет компилировать Java-программу сразу в нативный код.
Поэтому очевидно, что слухи о Java, которая работает быстрее C++, заметно преувеличены.
Очевидно лишь то, что Вы плохо разбираетесь в том, о чем пишете. Известно, что DAC (dynamic adaptive compiler, разновидность JIT), коим обладает JVM, способен порождать более оптимальный нативный код, нежели чем статический ahead-of-time компилятор для C++ или любого другого языка. Дело в том, что во время исполнения программы компилятору известно гораздо больше о платформе и о runtime окружении. Вот лишь некоторые из оптимизаций, недоступных C++ компиляторам, которые делает JVM в runtime: девиртуализация (замена виртуальных вызовов на статические), динамическая профиляция (ипользования информации о том, какие ветки исполняются чаще), использование архитектурных особенностей процессора, на котором в данный момент исполняется программа (SSE, NUMA и т.п.)
Короче говоря, прежде чем писать об интерпретаторах, изучите предмет. Говорить об интерпретации Javascript, PHP, Perl, Python, Java и даже не упомянуть о понятии виртуальной машины… На кого бы ни была рассчитана статья, она по меньшей мере просто бесполезна, и, более того, не соответствует действительности.
Как всё интересно… Где-то я это видел. Кажется, в учебнике по информатике за 11 класс 1989 года выпуска. В то время не было байткода, форт был в зачатках и о функциональном программировании мало кто задумывался. По состоянию на 1989 год статья более-менее верна.
В 89 уже и байткод был всякоразный, и JIT-компиляторы, и гибриды компиляторов с интерпретаторами.
Был? Ну я тогда был ещё маленький и тот учебник было наше всё.
Вот чего тогда не было точно, так это ни одного вменяемого учебника.
Да ладно! Я тот учебник вспоминаю с большой ностальгией.
Теория конечных автоматов, векторая графика, метод градиентного спуска и метод монте-карло, численные методы интегрирования, пределы, фон-неймановская и гарвардские архитектуры, теория массового обслуживания, теория множеств… Я всего и не вспомню. Учебник был близок к совершенству — потому что всё это давал в очень ясной и понятной для 8-классника форме. Я его читал с запоем.
Теория конечных автоматов, векторая графика, метод градиентного спуска и метод монте-карло, численные методы интегрирования, пределы, фон-неймановская и гарвардские архитектуры, теория массового обслуживания, теория множеств… Я всего и не вспомню. Учебник был близок к совершенству — потому что всё это давал в очень ясной и понятной для 8-классника форме. Я его читал с запоем.
мде. так и хочется сказать. автор, поизучай ассемблерный листниг того, что на выходе дает… ну тот-же самый gcc, со всеми оптимизациями. хотя бы. для начала…
Автор, а зачем вы так бредите? У вас какие-то проблемы, да?
Почему это Java и C# угодили в «интерпретаторы»? Вы вообще, хотя бы поверхностно, представляете себе, что такое интерпретатор, и чем он от компилятора отличается?
…
Почитал дальше. Автор действительно не имеет ни малейшего представления о том, что такое языки программирования, интерпретаторы и компиляторы.
Почему это Java и C# угодили в «интерпретаторы»? Вы вообще, хотя бы поверхностно, представляете себе, что такое интерпретатор, и чем он от компилятора отличается?
…
Почитал дальше. Автор действительно не имеет ни малейшего представления о том, что такое языки программирования, интерпретаторы и компиляторы.
Статья — форменный бред. По пунктам:
Java, C#, Visual Basic (.NET-версии) — не интерпретируемые. Для Javascript существуют JIT-компиляторы. Бред.
Не в тему. Незнание среды тут, как правило, не при чем. Люди, читавшие только «Ххх за N дней для профи», обычно натыкаются на проблему «у меня везде быдлокод и быдлоархитектура, я не знаю как мне добавить еще функционала, не сломав что-нибудь». До того, чтобы упереться в проблеммы производительности из-за интерпретации, у них дело не доходит.
Эта классификация использовалась еще до моего рождения. Современные языки в эту классификацию не вписываются. Пример: куда пихать C#? Он не ассемблер, не интерпретируемый, и не относится к компилируемым в бинарный код языкам. Неоднозначная ситуация.
Классификация языков вообще дело неоднозначное, выше в комментариях приводились примеры.
Нет. Из знания ассемблера не вытекает знание тонкостей работы процессора. Для этого нужно знать, как работает кэш, конвейер, что такое суперскалярность, в чем разница между скалярной и векторной обработкой, что такое аппаратная многопоточность… Список, разумеется, далеко не полный.
Интерпретатор — вообще не язык, это программа. Интерпретация же уже не является вершиной эволюции, выше нее, как минимум, JIT-компиляция. Список языков здесь тоже неверен.
Интересно, как же люди пишут кроссплатформенные приложения (например, игры) под разные системы?
Такие процессоры, вообще-то, существуют.
Предлагаете не использовать сторонние библиотеки, а все писать самостоятельно? Удачи.
Про работу со строками были комментарии выше. Отмечу лишь, что из известных мне языков ни один не использует UTF-8 в качестве внутреннего представления строк.
Вывод: автор вообще не понимает, о чем пишет. А учитывая, что статья, как утверждает автор, рассчитана на начинающих программистов — она вообще вредна.
Javascript, PHP, Perl, Python, Java, C#, Basic,… (как видно все они одного семейства — интерпретаторы).
Java, C#, Visual Basic (.NET-версии) — не интерпретируемые. Для Javascript существуют JIT-компиляторы. Бред.
Требовался программист на язык “X”, купили книгу “X за 2 недели” и через 3 недели – мы уже пишем какой-то проект на “X”. А спустя несколько тысяч строк кода или после того, как база данных обросла реальными данными, проект начинает нещадно тормозить.
Не в тему. Незнание среды тут, как правило, не при чем. Люди, читавшие только «Ххх за N дней для профи», обычно натыкаются на проблему «у меня везде быдлокод и быдлоархитектура, я не знаю как мне добавить еще функционала, не сломав что-нибудь». До того, чтобы упереться в проблеммы производительности из-за интерпретации, у них дело не доходит.
Для начала давайте разберемся в классах языков программирования. Я бы их разбил на 3 группы
Эта классификация использовалась еще до моего рождения. Современные языки в эту классификацию не вписываются. Пример: куда пихать C#? Он не ассемблер, не интерпретируемый, и не относится к компилируемым в бинарный код языкам. Неоднозначная ситуация.
Классификация языков вообще дело неоднозначное, выше в комментариях приводились примеры.
Если вы умеете программировать на ассемблере, значит, вы знаете все нюансы работы железа
Нет. Из знания ассемблера не вытекает знание тонкостей работы процессора. Для этого нужно знать, как работает кэш, конвейер, что такое суперскалярность, в чем разница между скалярной и векторной обработкой, что такое аппаратная многопоточность… Список, разумеется, далеко не полный.
Интерпретаторы — эти языки представляют собой высшую ступень эволюции: Javascript, PHP, Perl, Python, Java, C#, Basic…
Интерпретатор — вообще не язык, это программа. Интерпретация же уже не является вершиной эволюции, выше нее, как минимум, JIT-компиляция. Список языков здесь тоже неверен.
Если под Linux есть функция “Z”, а под Windows ее нет, то вам придётся либо обойтись без нее, либо ваша программа будет работать только под Linux (например, функции работы с файловой системой).
Интересно, как же люди пишут кроссплатформенные приложения (например, игры) под разные системы?
Поэтому очевидно, что слухи о Java, которая работает быстрее C++, заметно преувеличены. И это останется так, пока процессоры не научатся понимать байт-код Java.
Такие процессоры, вообще-то, существуют.
А вот в интерпретаторах слепое погружение в сторонние абстрактные функции пагубно.
Предлагаете не использовать сторонние библиотеки, а все писать самостоятельно? Удачи.
В интерпретируемых языках работа со строками стала настолько прозрачной, что тот факт, что это одни из самых ресурсо-затратных операций, абсолютно не очевиден.
Про работу со строками были комментарии выше. Отмечу лишь, что из известных мне языков ни один не использует UTF-8 в качестве внутреннего представления строк.
Вывод: автор вообще не понимает, о чем пишет. А учитывая, что статья, как утверждает автор, рассчитана на начинающих программистов — она вообще вредна.
Java, C#, Visual Basic (.NET-версии) — не интерпретируемые. Для Javascript существуют JIT-компиляторы. Бред.
После множества недовольных признаю, таки, ошибку. Не удачно выбрал слово. Хотел объединить все языки, программы которых не являются самостоятельным приложением, а требуют некую виртуальную машину. Как человеку, постоянно сидящиму последнее время на PHP/Javascript, первым в голову пришло «интерпретаторы». А как уже исполняются эти файлы у пользователя, построчно или с прекомпиляцией, считаю не критичным, поскольку та или иная методика может измениться при обновлении виртуальной машины и разработчика это событие скорее всего не затронет.
Но немного подумав еще, думаю вообше надо было выделить языки, в которых выделенные «узкие места» не очевидны. Например та же работа со строками на столько прозрачна, что начинающему нет смысла задумываться как оно работает.
Незнание среды тут, как правило, не при чем. Люди, читавшие только «Ххх за N дней для профи», обычно натыкаются на проблему «у меня везде быдлокод и быдлоархитектура, я не знаю как мне добавить еще функционала, не сломав что-нибудь». До того, чтобы упереться в проблеммы производительности из-за интерпретации, у них дело не доходит.
А вы не считаете, что пренебрежение строками и чужими библиотеками — это составляющая того, что вы называете «быдлокод»?
Из знания ассемблера не вытекает знание тонкостей работы процессора. Для этого нужно знать, как работает кэш, конвейер, что такое суперскалярность, в чем разница между скалярной и векторной обработкой, что такое аппаратная многопоточность… Список, разумеется, далеко не полный.
По мне так знание языка подразумевает и знание архитектуры, а не только синтаксиса. Кому нужно только знание синтаксиса в работе?
Интересно, как же люди пишут кроссплатформенные приложения (например, игры) под разные системы?
ну я же не отсекал все возможности файловой системы в примере. Но есть финкции, которые не везде работают одинаково если вообще работают. К примеру в PHP есть функция flock(), которая под Windows себя ведет не так как под *nix.
Такие процессоры, вообще-то, существуют.
Спасибо за информацию! Не знал. Ссылчку не дадите для большего образования?
Предлагаете не использовать сторонние библиотеки, а все писать самостоятельно? Удачи.
Нет, это крайность. Предлагаю не пользоваться стороннимми библиотеками, если встроенный функционал не сильно усложняет задачу, в местах где скорость критична.
Про работу со строками были комментарии выше. Отмечу лишь, что из известных мне языков ни один не использует UTF-8 в качестве внутреннего представления строк.
UTF-8 — это частный случай. Есть другие UTF. Могут еще какие-то появиться…
Вывод для себя: мое абстрактное видение языков программирования слишком не ясное для большинства, кто предпочитает оперировать официальными точными определениями. И зря, я все-таки, ввел свои определения групп языков. Слишком оно отвлекло от основной идеи.
P.S. спасибо за конструктивную критику! :)
"мое абстрактное видение языков программирования слишком не ясное для большинства, кто предпочитает оперировать официальными точными определениями"
Повторю еще раз — нет у вас никакого абстрактного видения. У вас каша в голове, что типично для самоучек. У вас нет системы и нет никакого понимания общей картины.
"Слишком оно отвлекло от основной идеи."
Ну так ваша «основная идея» тоже абсолютно неверна. Вы не там и не так узкие места ищете, и даете в целом очень глупые и вредные советы, следуя которым начинающие программисты будут писать редкостный говнокод. Может, вы и сами тоже пишете исключительно говнокод?
Повторю еще раз — нет у вас никакого абстрактного видения. У вас каша в голове, что типично для самоучек. У вас нет системы и нет никакого понимания общей картины.
"Слишком оно отвлекло от основной идеи."
Ну так ваша «основная идея» тоже абсолютно неверна. Вы не там и не так узкие места ищете, и даете в целом очень глупые и вредные советы, следуя которым начинающие программисты будут писать редкостный говнокод. Может, вы и сами тоже пишете исключительно говнокод?
если вы ее не понимаете или она не укладывается в ваше представление — это не значит что у меня его(видения) нет. Я могу судить только по отношению к моим знаниям других, кто со мной работал, работает или просто обращается ко мне за помощью.
Могу только согласиться с неумением письменно понятно выражаться, так как не писатель. Ну и в отсутствии владения официальной терминологией.
А вопрос качества моего или вашего кода тут обсуждать нет смысла. Безперспективняк, так сказать :)
P.S. берите пример как надо комментировать у «Romuchos». Его комментарии хоть можно обсудить… А ваше «автор дурак» абсолютно бессмыссленны как для автора, так и для других читателей.
Могу только согласиться с неумением письменно понятно выражаться, так как не писатель. Ну и в отсутствии владения официальной терминологией.
А вопрос качества моего или вашего кода тут обсуждать нет смысла. Безперспективняк, так сказать :)
P.S. берите пример как надо комментировать у «Romuchos». Его комментарии хоть можно обсудить… А ваше «автор дурак» абсолютно бессмыссленны как для автора, так и для других читателей.
"если вы ее не понимаете или она не укладывается в ваше представление — это не значит что у меня его(видения) нет"
То, что у вас нет видения, следует из того, что вы пишете глупости. Не потому, что не писатель, а потому, что не знаете предмета. Рассуждаете на темы, в которых совершенно не разбираетесь.
Искренне желаю вам осознания своего реального уровня и всяческого творческого и интеллектуального роста. Пока не осознаете, насколько ваши знания далеки от реальности, роста не будет.
Искренне желаю вам осознания своего реального уровня и всяческого творческого и интеллектуального роста. Пока не осознаете, насколько ваши знания далеки от реальности, роста не будет.
UFO just landed and posted this here
Sign up to leave a comment.
Узкие места интерпретаторов