Сообщение Re[22]: Java vs C# vs C++ от 02.10.2015 20:34
Изменено 02.10.2015 20:35 alexzzzz
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>>>Смысл есть. Например выше сравнили скорость работы высокоуровневого кода — вполне полезный тест
A>>Я не вижу практического смысла. Пишу, допустим, я программу на языке А. Вижу, что в одном месте тормозит. Беру и оптимизирую в рамках, допускаемых языком А. На язык Б я начну смотреть, только когда предел оптимизации достигнут, а всё равно тормозит, и точно понятно, что можно сделать быстрее.
EP>Так я и не говорю что нужно сразу бежать на другой язык. Где-то да, вполне уместно остаться в рамках одного языка, пусть и напедалив error-prone boilerplate низкоуровневого кода
А если бы говорил, что нужно сразу бежать на другой язык, то сравнение высокоуровневого кода имело бы смысл.
A>>Но к этому времени никакого высокоуровнего кода уже не останется ― нечего сравнивать.
EP>В каком смысле?
Смотри, допустим, есть метод на C#, который принимает ICollection<T>, как-то сложно её анализирует и даёт на выходе IDictionary<TKey, TValue>. И при этом тормозит. Допустим, кто-нибудь пишет аналог этого метода на C++ и указывает, что он работает в сто раз быстрее. Что это знание даёт практически?
Я ведь не смогу из C# передать в C++ ICollection<T> и получить IDictionary<TKey, TValue>.
— либо код на C++ должен будет понимать детали реализации типов в .Net, и получится уже не высокоуровневый код;
— либо передавать и возвращать придётся не абстрактные коллекции абстрактных типов, а какие-нибудь банальные массивы с числами или указатели на блоки памяти с числами, и снова получится не высокоуровневый код.
Логичный вариант ― не смотреть на другие языки, а сначала убрать лишние абстракции и чё-нибудь оптимизировать в коде на исходном языке. Стало достаточно быстро ― замечательно. Не стало ― смотрим в сторону С++, пробуем написать на нём аналог и сравниваем скорость. При этом сравниваем, естественно, с оптимизированной низкоуровневой версией. Ведь обогнать теперь нужно именно её.
EP>>>Смысл есть. Например выше сравнили скорость работы высокоуровневого кода — вполне полезный тест
A>>Я не вижу практического смысла. Пишу, допустим, я программу на языке А. Вижу, что в одном месте тормозит. Беру и оптимизирую в рамках, допускаемых языком А. На язык Б я начну смотреть, только когда предел оптимизации достигнут, а всё равно тормозит, и точно понятно, что можно сделать быстрее.
EP>Так я и не говорю что нужно сразу бежать на другой язык. Где-то да, вполне уместно остаться в рамках одного языка, пусть и напедалив error-prone boilerplate низкоуровневого кода
А если бы говорил, что нужно сразу бежать на другой язык, то сравнение высокоуровневого кода имело бы смысл.
A>>Но к этому времени никакого высокоуровнего кода уже не останется ― нечего сравнивать.
EP>В каком смысле?
Смотри, допустим, есть метод на C#, который принимает ICollection<T>, как-то сложно её анализирует и даёт на выходе IDictionary<TKey, TValue>. И при этом тормозит. Допустим, кто-нибудь пишет аналог этого метода на C++ и указывает, что он работает в сто раз быстрее. Что это знание даёт практически?
Я ведь не смогу из C# передать в C++ ICollection<T> и получить IDictionary<TKey, TValue>.
— либо код на C++ должен будет понимать детали реализации типов в .Net, и получится уже не высокоуровневый код;
— либо передавать и возвращать придётся не абстрактные коллекции абстрактных типов, а какие-нибудь банальные массивы с числами или указатели на блоки памяти с числами, и снова получится не высокоуровневый код.
Логичный вариант ― не смотреть на другие языки, а сначала убрать лишние абстракции и чё-нибудь оптимизировать в коде на исходном языке. Стало достаточно быстро ― замечательно. Не стало ― смотрим в сторону С++, пробуем написать на нём аналог и сравниваем скорость. При этом сравниваем, естественно, с оптимизированной низкоуровневой версией. Ведь обогнать теперь нужно именно её.
Re[22]: Java vs C# vs C++
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>>>Смысл есть. Например выше сравнили скорость работы высокоуровневого кода — вполне полезный тест
A>>Я не вижу практического смысла. Пишу, допустим, я программу на языке А. Вижу, что в одном месте тормозит. Беру и оптимизирую в рамках, допускаемых языком А. На язык Б я начну смотреть, только когда предел оптимизации достигнут, а всё равно тормозит, и точно понятно, что можно сделать быстрее.
EP>Так я и не говорю что нужно сразу бежать на другой язык. Где-то да, вполне уместно остаться в рамках одного языка, пусть и напедалив error-prone boilerplate низкоуровневого кода
A>>Но к этому времени никакого высокоуровнего кода уже не останется ― нечего сравнивать.
EP>В каком смысле?
Смотри, допустим, есть метод на C#, который принимает ICollection<T>, как-то сложно её анализирует и даёт на выходе IDictionary<TKey, TValue>. И при этом тормозит. Допустим, кто-нибудь пишет аналог этого метода на C++ и указывает, что он работает в сто раз быстрее. Что это знание даёт практически?
Я ведь не смогу из C# передать в C++ ICollection<T> и получить IDictionary<TKey, TValue>.
— либо код на C++ должен будет понимать детали реализации типов в .Net, и получится уже не высокоуровневый код;
— либо передавать и возвращать придётся не абстрактные коллекции абстрактных типов, а какие-нибудь банальные массивы с числами или указатели на блоки памяти с числами, и снова получится не высокоуровневый код.
Логичный вариант ― не смотреть на другие языки, а сначала убрать лишние абстракции и чё-нибудь оптимизировать в коде на исходном языке. Стало достаточно быстро ― замечательно. Не стало ― смотрим в сторону С++, пробуем написать на нём аналог и сравниваем скорость. При этом сравниваем, естественно, с оптимизированной низкоуровневой версией. Ведь обогнать теперь нужно именно её.
EP>>>Смысл есть. Например выше сравнили скорость работы высокоуровневого кода — вполне полезный тест
A>>Я не вижу практического смысла. Пишу, допустим, я программу на языке А. Вижу, что в одном месте тормозит. Беру и оптимизирую в рамках, допускаемых языком А. На язык Б я начну смотреть, только когда предел оптимизации достигнут, а всё равно тормозит, и точно понятно, что можно сделать быстрее.
EP>Так я и не говорю что нужно сразу бежать на другой язык. Где-то да, вполне уместно остаться в рамках одного языка, пусть и напедалив error-prone boilerplate низкоуровневого кода
A>>Но к этому времени никакого высокоуровнего кода уже не останется ― нечего сравнивать.
EP>В каком смысле?
Смотри, допустим, есть метод на C#, который принимает ICollection<T>, как-то сложно её анализирует и даёт на выходе IDictionary<TKey, TValue>. И при этом тормозит. Допустим, кто-нибудь пишет аналог этого метода на C++ и указывает, что он работает в сто раз быстрее. Что это знание даёт практически?
Я ведь не смогу из C# передать в C++ ICollection<T> и получить IDictionary<TKey, TValue>.
— либо код на C++ должен будет понимать детали реализации типов в .Net, и получится уже не высокоуровневый код;
— либо передавать и возвращать придётся не абстрактные коллекции абстрактных типов, а какие-нибудь банальные массивы с числами или указатели на блоки памяти с числами, и снова получится не высокоуровневый код.
Логичный вариант ― не смотреть на другие языки, а сначала убрать лишние абстракции и чё-нибудь оптимизировать в коде на исходном языке. Стало достаточно быстро ― замечательно. Не стало ― смотрим в сторону С++, пробуем написать на нём аналог и сравниваем скорость. При этом сравниваем, естественно, с оптимизированной низкоуровневой версией. Ведь обогнать теперь нужно именно её.