Явная типизация (C#(mono), Java(openjdk) vs неявная CL (SBCL, ABCL): Производительность

В твоем случае это связано с тем, видимо, что эти переменные динамические получают значения в рантайме, т.е. компилятр там ниче не сопримизирует. К типизации это не имеет отношения.

Но вообще, динамика не всегда означает падение производительности, это с компиляцией связано больше, а вот пример быстрого интерпретатора:

http://habrahabr.ru/post/177791/

Там все динамическое, и переменные и типы

В шарпе есть var, который просто выводит тип на статике без потери производительности в рантайме.

Кстати, а не путаешь ли ты явную/неявную типизации и статическую/динамическую типизации?

IRL мне преподаватель сказал, что реализации динамических языков медленнее чему у не динамических.

CL ведь динамический ЯП?

В шарпе есть var, который просто выводит тип на статике без потери производительности в рантайме.

Я думаю, под динамическими переменными имелось в виду это

Нет я про object.

IRL мне преподаватель сказал, что реализации динамических языков медленнее чему у не динамических.

Почему ты школьного учителя называешь преподавателем, малыш?

q - динамический язык с сильной типизацией. Nuff said.

Чему же вас там учат, если у тебя, как видно из ОП, нет внятного представления, почему, собственно, это самое «теоретически» имеет место быть.

Это из-за постоянной проверки типов?

Ага а в CL в целях оптимизации (которая обязательно нужна чтобы догнать другие производительные языки) делают код явно типизированным.

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

И тут мы переходим от абстракций текстовых данных к вещам, связанным к конкретной реализацией исполнения программы.

Ты заводишь некоторую переменную, не указывая её строгий тип, потом передаешь эту переменную в качестве аргумента некоторой другой функции. Как будет представлена эта переменная в памяти? Как будет осуществлятся взаимодействие с этой переменной?

В динамических языках часто можно увидеть, что компилятор/интерпретатор делает очень неоптимальные, тяжелые и уродливые решения. Образно выражаясь, там где нужен трубач или скрипач или виолончелист появляется этакий «человек-оркестр», вместо аккуратного узкоспециализированного решения, используется громозкое универсальное.

Говорить что язык сам по себе тормозной некоректно, тормозит конкретная реализация, но нельзя с научной строгостью делать выводы о производительности той или инной реализации по структуре её исходного языка.

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

Именно из-за этого компиляторы CL должны по определению быть менее производительными?

Ничего «по определению» они не должны.

З.Ы. Мое личное мнение, что тотальная динамическая типизация, как идея - полное говно.

Здесь ответ на твой вопрос. Для Ъ: явная спецификация типов, очевидно, увеличивает производительность.

Да, делают. Однако может быть удобно сначала написать код без указания типов, а потом проставить их там, где нужно. Это же годно, когда язык прототипирования и реализации — одно и то же :)

В машинном коде команды оперируют с конкретными типами. Когда компилятор компилирует примитивную операцию, если он знает типы переменных, он генерирует соответствующую команду. Если он не знает типы переменных, он должен извлечь тип из каждой переменной, сравнить его и исходя из этих типов в каждом ветвлении поставить команду (или выброс ошибки). Можно придумывать разного рода оптимизации, но корень проблемы лежит тут и от него можно избавиться только типизировав переменные, чтобы у компилятора была информация о том, какие значения лежат в этих переменных.

Да, делают

Да, делают. Из ЯП ИИ сделали недоСи. Си, однако, не догнали, а ЯП в помойку превратили.

Явность или неявность типизации на производительность не влияет.

А разве var не на этапе компиляции тип выводит? Зачем делать это в рантайме?

А это правда, что CL как динамический язык будет проигрывать в производительности чисто теоретически?

При прочих равных - да.

Только не надо путать «динамическую» типизацию с «неявной».

Че ты городишь? Приведение типов в рантайме требует времени, школоло хреново.

Эти понятия связаны, однако. Покажи мне ЯП с неявной статической типизацией.

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

В этом мере сравниваются только реализации, в рамках одно инструментария или нет - не важно.

Штука в том, что реализация реализует какие-то конструкции, а эти конструкции могут могут иметь разную идеальную реализацию на текущем инструментарии.

И тут мы переходим от абстракций текстовых данных к вещам, связанным к конкретной реализацией исполнения программы.

Закорючка в программе - это представление конструкции языка, мы говорит о конструкциях языка.

Ты заводишь некоторую переменную, не указывая её строгий тип, потом передаешь эту переменную в качестве аргумента некоторой другой функции. Как будет представлена эта переменная в памяти? Как будет осуществлятся взаимодействие с этой переменной?

У каждого типа есть свой набор обработчиков. Когда задан строгий тип - просто ставится обработчик этого типа.

Когда же у тебя переменная без типов, то надо: а) хранить её тип. б) делать таблицу переходов в текущих реалиях в примитивном случае. Т.е. какой-обработчик переменной, который будет запускать обработчик типа в зависимости от типа.

Это будет всегда медленней by design в не зависимости от того, что ты там вещаешь и как бы адепты рантайм типа не рвали себе жопы.

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

В динамических языках часто можно увидеть, что компилятор/интерпретатор делает очень неоптимальные, тяжелые и уродливые решения. Образно выражаясь, там где нужен трубач или скрипач или виолончелист появляется этакий «человек-оркестр», вместо аккуратного узкоспециализированного решения, используется громозкое универсальное.

Обычные рассуждения пацана, который о матчасти знает из мифов и легенд от соседей по яслям.

Говорить что язык сам по себе тормозной некоректно, тормозит конкретная реализация, но нельзя с научной строгостью делать выводы о производительности той или инной реализации по структуре её исходного языка.

Можно, я тебе уже объяснил почему. Есть сложность реализации и сложность исполнения(т.е. цена рантайма в чистом коде). Дак вот, сложность исполнения у сишки 0, у пхп 100500 by design. И как бы ты тут не рассуждал так будет всегда.

Тыж вроде плюсовик. Дак вот, класс будет всегда тормазнее и больше сишной структуры, из-за одной волшебной штучки - vtbl. Это цена исполнения, и эту vtbl ты не выпилишь, ибо она нужна для реализации конструкций/принципов языка.

Ты(конпелятор) можешь свести класс к сишной структуре, но для этого тебе надо не юзать ни один из фичей, которые требуют vtbl. Но это в конкретном случае, а в общем будет всегда тормазней.

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

Является строгим утверждением, кроме тех случаев когда можно свести всю динамику ко статике - это уже называется автотипы и такой код теряет все фичи динамизма и просто не имеет смысла в динамическом языке.

Ничего «по определению» они не должны.

Должны, по определению. У языка есть одна штука уже близкая к реальному миру, а не абстрактная - как реализация конструкций ложится на текущее железо.

Реализация недоязычка не ложится на текущее железо никак, вернее как-то, но через жопу. Поэтому будет всегда медленней. Не зря же для лиспов пилили свои процессоры.

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

Это как сейчас плавучка на х86. Вот пацаны вещают, что типа плавучка стала на х86 работать так же(хотя и это враньё), как цилые числа. Нет, всё не так - это целые числа стали тормазить так же, как плавучка.

Штука в том, что плавучка имеет и цену реализации и цену исполнения выше целых чисел. Это значит, что как бэ кто не рвал жопу - они(реализации) будут всегда медленнее и сложнее. Даже если они будут такие же по производительности, то они будут больше(а тут больше == медленнее).

З.Ы. Мое личное мнение, что тотальная динамическая типизация, как идея - полное говно.

Любая динамическая типизация говно, реализуется проще пареной репы на сишке и не нужна.

ML.

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

Как такое может быть? Ты не скомпилишь код с такой типизацией.

Не выведешь ты их в компилтайме. Даже в той же решетке оно сверху на изоленту прикручено

Утиная типизация (duck typing; неявная динамическая типизация) — это когда тип объекта определяется поддерживаемым контрактом, а не действительными интерфейсами или базовыми типами, от которых он унаследован. Утиная типизация распространена в некоторых библиотеках шаблонов С++, где можно делать нечто подобное следующему коду С#, который не компилируется:

// Это не компилируется! ! !
class С<Т>
{
static public void DoWork( T item )  {
item.DoWork();
   }
}

При попытке компиляции этого кода выдается следующее сообщение об ошибке:

error CS1061: ‘Т’ does not contain a definition for ‘DoWork’ and no extension method ‘DoWork’ accepting a first argument of type ‘T’ could be found (are you missing a using directive or an assembly reference?) ошибка CS1061: T не содержит определения DoWork, и не обнаружены расширяющие методы DoWork,которые принимают первый аргумент типа Т (возможно, пропущена директива using или ссылка на сборку)

реализуется проще пареной репы на сишке

Что значит реализуется? Путем написания интерпретатора си на асме? Lol. Скажи проще, без батхерта. Сишка — недоязычок, который тебя бьет по рукам за малейшее отступления от анального рабства статики. Он не может ничего, что может нормальный яп. заруби себе на носу.

Что значит реализуется?

Для справки - все недоязычки написаны на сишке.

Путем написания интерпретатора си на асме?

Си на асм? ААхахах. К чем мы его приплёл сюда? Чтоб люди увидели, что такие «сложные» слова знаешь?

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

Ещё раз, перечитай 2-ю строчку.

Он не может ничего, что может нормальный яп. заруби себе на носу.

оО, как же я это люблю. О5 нулёвый балабол лучше меня знает что может сишка.

Давай сыграем с игру - ты пишешь порятнку на недоязычке, поведение которой я не смогу реализовать на сишке, а я это реализую на сишке. Я даю тебе на доказательство 3попытки, после 3-й ты выходишь в окно, ок?

Для справки - все недоязычки написаны на сишке.

Какое это имеет отношение к вопросу? И не все.

Давай сыграем с игру

Нет. На сишке, и на любом другом ЯП, ты можешь написать хоть исполнитель другого языка, интерпретатор или компилятор. Для того, чтобы осознать, что си сосет, тебе достаточно написать код, непосредственно на си, который в си не пишется, например, те же неявные типы. Это в других яп можно сделать а в си — нельзя. Этого достаточно.

Ты еще не понял, что ввязался в спор с очередной реинкарнацией царя-суперхаккиллера? Устанешь спорить ведь :-).

Какое это имеет отношение к вопросу? И не все.

Прямое.

Нет.

Как же ты слился инстантно.

На сишке, и на любом другом ЯП, ты можешь написать хоть исполнитель другого языка, интерпретатор или компилятор.

Нет. Именно поэтому ни на каком ЯП, кроме сишки исполнитель и интерпритатор не написан. Гениально.

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

Сходика напиши жабу на пхп, а я поржу.

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

Что-то я знаю и писал ан сишке на порядке лучше и больше тебя, но почему-то я это не осознаю, а нулёвая балаболка осознаёт?

Пример кода, который мне поможет это сознать. Показывай пример кода, который на си не пишется на каком-то недоязычке, а потом его же на Си.

Этого достаточно.

Кому? Тыж при первой возможности как-то внятно доказать свой выхлоп слился в нулину. И сейчас сольёшься. Выкатывай, показывай, доказывай, а не балаболь.

Именно поэтому ни на каком ЯП, кроме сишки исполнитель и интерпритатор не написан. Гениально.

Да ты вообще далек, по-ходу. это не интересно даже.

Показывай пример кода, который на си не пишется на каком-то недоязычке, а потом его же на Си.

Ну ты вроде обещал неявные типы, их и изобрази для начала, lol

foo=false
foo+1
foo+"bar"

Твой ход

Не выведу, поэтому не существует таких языков, как ML, Haskell, Scala, F#.

Где пруф?

Haskel

Да ты сбрендил, школьнек? В этом дерьме ты не то что неявное приведение, ты там явно запаришься приводить. Гуляй Вася, ты доказал свою компетентность сполна.

Полудурок аноним не различает приведение и вывод. Ну что же поделаешь, на то он и полудурок аноним.

Это не код, а ссанина.

Что ты мне хочешь показать, что в сишке это будет так:

set(foo, false);
add(foo, 1);
add(foo, "bar");
//либо
set(foo, false);
foo = add(foo, 1);
foo = add(foo, "bar");

Т.е. нету переопределения операторов, я тебе не обещал «синтаксическую» корректность.

#define autodecl(name, init) typeof(({init;})) name = ({init;})
int main(void) {
  autodecl(a, 123ul);
  if(!__builtin_types_compatible_p(typeof(a), uint64_t))
    fprintf(stderr, "fail\n");
  fprintf(stderr, "%lu, %lu\n", sizeof(a), a);

  autodecl(str, "124");
  if(!__builtin_types_compatible_p(typeof(str), char *))
    fprintf(stderr, "fail\n");
  fprintf(stderr, "%lu, %s\n", sizeof(str), str);
}

Что дальше?

Еще раз, баран, то о чем говорилось изначально, о чем ты говорил, гребаная неявная типизация, это привидение типов а не вывод. То что ты несешь, это просто п-ц.

Неявная типизация - это отсутствие необходимости явного объявления типов используемых переменных, что для статической типизации означает вывод типов, например алгоритмом Хиндли-Милнера. То, что вы с ТСом за компанию необразованные дегенераты, этот факт никаким образом не меняет.

Ну и каков результат операций add(foo, 1) и add(foo, «bar»)?

Неявная типизация, латентная типизация или утиная типизация (калька с англ. Duck typing) — вид динамической типизации, применяемой в некоторых языках программирования (Perl, Smalltalk, Objective-C, Python, Ruby, JavaScript, Groovy, ColdFusion, Boo), когда границы использования объекта определяются его текущим набором методов и свойств, в противоположность наследованию от определённого класса. То есть считается, что объект реализует интерфейс, если он содержит все методы этого интерфейса, независимо от связей в иерархии наследования и принадлежности к какому-либо конкретному классу.
http://ru.wikipedia.org/wiki/Утиная_типизация

ru

wikipedia

Давай свой пруф или умойся гавном.

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

Не вижу.

Да тот же * void. Тайпид и вперёд.

Тайпид делается так:

typedef char * string;
#define typeid(T) _Generic((T), int:0, float:1, double:2, string:3, uint32_t:4, uint64_t:5, int64_t:6)
#define print_typeid(a, b) fprintf(stderr, "a:%lu, b:%lu\n", typeid(a), typeid(b))


int main(void) {
  print_typeid(123, 123ul);
  print_typeid("123", "123");
}

Это уже динамическая типиизация. Ставь либо тип руками, либо юзай автодекл, либо юзай не чистые типы.

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

Я си не знаю. Скажи конкретно, каков результат этих операций. Какие данные на выхлопе и какой тип у тех данных.