Откуда берётся разница в скорости языков

Кроме алгоритма есть ещё и его оптимизация. Если выполнять любой алгоритм без оптимизации, будет тормозить сильнее питона. Все компиляторы/интерпретаторы оптимизируют по-разному.

Как работает программа, скомпилированная из C++: «по адресам a и b есть переменные целого типа, взять их сложить, записать по адресу c»

Как работает программа на python:

1) Найти в хеш-таблице адрес структуры данных, описывающей переменную a

2) Найти в хеш-таблице адрес структуры данных, описывающей переменную b

3) Проверить тип переменной a, если он не равен Integer то перейти к процедуре выкидывания исключения

4) Проверить тип переменной b ...

5) и т.д.

Некоторые языки выносят множество всякой дряни в рантайм. Например в ОБжСи можно вызывать методы у нулевого указателя. Я не спец, по компиляторам, но мне кажется, что это не приводит к сегфолту за счёт дополнительной проверки. Проверки при каждом обращении к каждому указателю. В Си такой проверки нет. Как нет и проверки на диапазоны массива.

Ахтунг ! Бабы инсталлируют мой Линукс ! Ты троллишь или действительно не понимаешь разницы между интерпретатором, виртуальной машиной, и компилятором ?

Например в ОБжСи можно вызывать методы у нулевого указателя.

В плюсах тоже можно, емнип.

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

емнип.

Изменяет.

Проверка типа переменной, КМК, есть и в C++. Нельзя же там сложить яблоко и 32?

Ответ кроется в кривых пука разработчиков.

Понимаю разницу, а вот как это сказывается на скорости - не знаю.

Жава не тормозит, вы все врети!!

Можно, если метод не обращается к внутренним данным, то есть не разыменовывает this.

Нет, ты не понимаешь разницы. Если бы понимал, то осознавал бы, что сложить 2 числа в машинном коде - это 1-2 такта процессора. А всосать строку кода из файла, расшифровать её, проинтерпретировать - это сотни тысяч тактов.

Проверка типа переменной, КМК, есть и в C++.

Только на этапе компиляции.

http://stackoverflow.com/questions/2505328/calling-class-method-through-null-...

Kokoko

Два чая этому господину

Это же undefined behavior

Её компилятор выполняет.

Проверка типа переменной, КМК, есть и в C++. Нельзя же там сложить яблоко и 32?

В С++ проверка происходит во время компиляции, а не в райнтайме.

Можно, если метод не обращается к внутренним данным, то есть не разыменовывает this.

Это UB.

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

Это не должно работать. Вероятно просто повезло.

Работает.

Ты когда-нибудь компилировал программы? Ты знаешь, сколько времени занимает компиляция? Java и Python делают это на ходу.

Обоснуй, почему не должно. Или почему должно падать

Ну пока идёт лишь обращение в функциям и не дёргаются переменные, то всё будет ок.
Функция она и в Африке функция, даже если её методом назовут:)
Но в общем случае получим сегфолт.
Да и вообще это противоречит здравому смыслу

Жабка — она на то и жабка, чтобы душить тормозить.

Java тормозит из-за GC и медленного старта, а так то она быстро работает.

Чем выше язык, тем он тормознее, верно и обратное.

В пхп можно, хехе, но он от этого не становится убербыстрым. Хотя, тормозят реализации, а не ЯП, я считаю.

Как работает программа, скомпилированная из C++: «по адресам a и b есть переменные целого типа, взять их сложить, записать по адресу c»

А потом появляются всякие «течки» и начинает тормозить не только программа, но и операционная система

Чем выше язык, тем он тормознее, верно и обратное.

Значит самый высокий язык - джава.

Удивительно, но даже гткшные приложения на питоне не так тормозят, как гткшные на джаве

Ты использовал java-gnome? У меня он очень быстро работал.

Ну хоть это и UB, и так писать не надо, с точки зрения того, как работает компилятор - вполне нормально, потому что в процессе компиляции:

class A { void f(int n) { ... } };

void a_f(A* p, int n) { ... }

Это UD по стандарту. В данном случае просто реализация такая.

В C++ вполне можно сделать ((my_structure*)0)->method();

А вот к чему это приведет - другой вопрос.

нет, не понимаете

В чем же UB? 0 - ничем с точки зрения языка не хуже любого другого указателя.

И если в адресном пространстве есть адрес 0, то даже сегфолта не будет.

например, на x86 в реальном режиме можно сделать что-то такое

class rm_interrupt {
    void (*handler)(void);
    public:
        void set_handler(void (*new_handler)(void)) {handler = new_handler;}
}
.....
void main(void)
{
    rm_interrupt *zero = 0;
    zero->set_handler(zero_int_hdl);
}

с чего бы? ещё как обязано. Х.func(a) == func(&X, a) на самом деле.

если Y == nullptr, то Y->func(a) == func(nullptr, a)

ну и чего, собственно? разыменование производится внутри функции, а не при вызове. поэтому вызов хоть и UB, но вполне безопасен, если вы знаете что делаете. более того, внутри метода может быть даже delete this.

Тред короткий — перед ответом его можно было прочитать.

Ниоткуда. Нет никакой разницы в скорости языков. Вообще нет и быть не может.

Дваждую, Томми подтверждает, ой, то есть то, что осталось от Томми.

уже) но поздно

Переформулирую вопрос: «Какого черта, на дворе уже почти 2015 год, а все это дерьмо умеет либо тормозить, либо очень сильно тормозить?»

man приведение типов.

О ДА!

Ниоткуда. Нет никакой разницы в скорости языков. Вообще нет и быть не может.

+1, для Си например есть как компиляторы, так и интерпретаторы, при чём тут вообще язык?

В последнее время уж слишком часто стали появляться типапосты с типатроллингом и «жабатормозит». Каникулы что ли?

Тяжело тебе жить. Что не вопрос - то троллинг в нём видится.