Comments 13
Для GCC — Go субпроект новый и по большей части вторичный. Со временем конечно разработчики допилят шаблоны оптимизации, как допилили для других языков, ну а пока мы имеем то что имеем. :-)
Я бы предпочёл, если бы больше людей на перешли с Go на Eiffel. В рамках проекта GNU это Liberty Eiffel, но я не уверен что это самый лучший из существующих свободных компиляторов. А достоинств у языка много, в том числе Си на выдаче в качестве промежуточного результата. Который в свою очередь можно оттранслировать в ассемблер и скормить gas. В итоге и программисты и майнтейнеры довольны. Ну и конечный юзер само собой.
Впрочем к статье это слабо относится, хотя читать было интересно, ага.
Впрочем к статье это слабо относится, хотя читать было интересно, ага.
Если это поделие не стало популярным за 30 лет, то скорее всего уже никогда не станет. В языке главное даже не он сам, а комьюнити. Закопать.
С похожиими доводами можно, к примеру, агитировать всех перейти с Java на Ada. Или с C++ на ObjC.
Так себе доводы.
Так себе доводы.
Довод был исключительно примера для и в контексте удобства для майнтейнера. И я не являюсь ни Eiffel-евангелистом, ни противником Go. По роду своей деятельности мне приходится сопровождать и поддерживать код, написанный на разных языках.
И раз уж была упомянута джава, то я считаю, что с неё можно и нужно перейти на любой другой язык. Но это, исключительно, — имхо.
Вы вольны писать на том языке, на котором вам удобнее.
Но замечу, что при прочих равных тот же «hello world» после компиляции на Си, Си++ и Го занимают: 10784, 11408 и 33720 байт.
Последнее не для холивара, а исключительно мой критерий в выборе языка для своих проектов. Хотя если нужно, то я и не брезгую Ассемблером. В инструкциях x86_64 и системных вызовах Linux бинарник тот же «Hello world» занимает вообще около 900 байт.
Если мне что-то нужно написать, то я использую либо Си, либо Си++ (в меньшей степени). А если нужно что-то оптимизировать, то подключаю ассемблер.
А «быстро-код» можно и на языке командной оболочки писать, чем бывает тоже грешу. В контексте одного дистрибутива живущего преимущественно в ОЗУ это вполне допустимо и нормально (в отличии от других интерпретируемых языков).
Собственно, на Eiffel я засмотрелся именно для «быстро-кода», так как мне кажется, что Go для этого неподходит. Но я буду рад, если меня кто-нибудь переубедит. :-)
И раз уж была упомянута джава, то я считаю, что с неё можно и нужно перейти на любой другой язык. Но это, исключительно, — имхо.
Вы вольны писать на том языке, на котором вам удобнее.
Но замечу, что при прочих равных тот же «hello world» после компиляции на Си, Си++ и Го занимают: 10784, 11408 и 33720 байт.
Время выполнения
bash-4.3# time ./hello
Hello world!
real 0m0.001s
user 0m0.001s
sys 0m0.000s
bash-4.3#
bash-4.3# time ./hello
Hello World!
real 0m0.003s
user 0m0.001s
sys 0m0.001s
bash-4.3#
bash-4.3# time ./hello
hello world
real 0m0.282s
user 0m0.030s
sys 0m0.007s
bash-4.3#
Hello world!
real 0m0.001s
user 0m0.001s
sys 0m0.000s
bash-4.3#
bash-4.3# time ./hello
Hello World!
real 0m0.003s
user 0m0.001s
sys 0m0.001s
bash-4.3#
bash-4.3# time ./hello
hello world
real 0m0.282s
user 0m0.030s
sys 0m0.007s
bash-4.3#
Последнее не для холивара, а исключительно мой критерий в выборе языка для своих проектов. Хотя если нужно, то я и не брезгую Ассемблером. В инструкциях x86_64 и системных вызовах Linux бинарник тот же «Hello world» занимает вообще около 900 байт.
Если мне что-то нужно написать, то я использую либо Си, либо Си++ (в меньшей степени). А если нужно что-то оптимизировать, то подключаю ассемблер.
А «быстро-код» можно и на языке командной оболочки писать, чем бывает тоже грешу. В контексте одного дистрибутива живущего преимущественно в ОЗУ это вполне допустимо и нормально (в отличии от других интерпретируемых языков).
Собственно, на Eiffel я засмотрелся именно для «быстро-кода», так как мне кажется, что Go для этого неподходит. Но я буду рад, если меня кто-нибудь переубедит. :-)
Ваш тест на скорость ниочем. В первую очередь время инициализации/деинициализации и время выполнения полезной работы — это разные вещи.
Ну и как всегда цена разработки и поддержки против цены оборудования.
Я не большой сторонник Go но это хороший язык который выполняет свою задачу. Есть свои проблемы, но у какого языка их нет? Ну и, конечно, всегда нужно применять нужные инструменты вовремя и с умом.
Ну и как всегда цена разработки и поддержки против цены оборудования.
Я не большой сторонник Go но это хороший язык который выполняет свою задачу. Есть свои проблемы, но у какого языка их нет? Ну и, конечно, всегда нужно применять нужные инструменты вовремя и с умом.
quasilyte Спасибо за подробный анализ!
Подскажите, были ли оформлены результаты в виде тикетов для gc?
Подскажите, были ли оформлены результаты в виде тикетов для gc?
Не особо.
Но если поискать в интернете, автоматическую векторизацию вроде как не хотят добавлять из-за потенциального замедления компиляции.
Новый calling convention уже давно обсуждается и там есть некоторые успехи в этом направлении. Тоже по Go трекеру можно найти.
mid-stack инлайнинг уже работает из коробки. Эвристики инлайнинга вроде тоже несколько раз подкручивали.
Сворачивание константных выражений тоже, скорее всего, улучшилось. Хотя чудес типа символического исполнения я бы не ждал.
Sign up to leave a comment.
GCCGO против «стандартной» реализации