Приветствую. Нашел пачку старых разных журналов, большую такую пачку. Ну и в особые минуты проглядываю. И видел я на сайте сообщения, гласящие: "подобно этому, в стародавние времена говорили подобным образом о кое-чем" (не будем уточнять). Но фактов не видел. Так вот:
PC Magazine/Russian edition, 3/94
"Библиотека потокового ввода-вывода языка Си++"
Кааре Кристиан, PC Magazine, January 11, 1994, p. 284
...
Не исключено, что новый подход покажется вам неудобным, так как iostream — более громоздкая и медленная библиотека, нежели stdio, но, согласитесь, что это небольшая плата за надежность и расширяемость, обусловленные возможностями объектно-ориентированных средств ввода-вывода.
...
> ...
> Не исключено, что новый подход покажется вам неудобным, так как iostream — более громоздкая и медленная библиотека, нежели stdio, но, согласитесь, что это небольшая плата за надежность и расширяемость, обусловленные возможностями объектно-ориентированных средств ввода-вывода.
> ...
В данном конкретном случае не было никакой необходимости жертвовать производительностью для "надежности и расширяемости, обусловленных объектно-ориентированными средствами ввода-вывода": можно было получить все сразу.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Real 3L0, Вы писали:
R3>Приветствую. Нашел пачку старых разных журналов, большую такую пачку. Ну и в особые минуты проглядываю. И видел я на сайте сообщения, гласящие: "подобно этому, в стародавние времена говорили подобным образом о кое-чем" (не будем уточнять). Но фактов не видел. Так вот:
R3>Не исключено, что новый подход покажется вам неудобным, так как iostream — более громоздкая и медленная библиотека, нежели stdio, но, согласитесь, что это небольшая плата за надежность и расширяемость, обусловленные возможностями объектно-ориентированных средств ввода-вывода.
А при чём тут объектно-ориентированные средства вывода? Что там объектно-ориентированого?
Здравствуйте, Кодёнок, Вы писали:
Кё>А при чём тут объектно-ориентированные средства вывода? Что там объектно-ориентированого?
Во-первых, в старой литературе особой разницы между ОО и object-based могли не делать (подчеркивали разницу с процедурным printf). Во-вторых, в стандартных потоках объектно-ориентированные streambuf'ы.
Здравствуйте, Павел Кузнецов, Вы писали: ПК>В данном конкретном случае не было никакой необходимости жертвовать производительностью для "надежности и расширяемости, обусловленных объектно-ориентированными средствами ввода-вывода": можно было получить все сразу.
Беспристрастнее нужно быть. Это сообщение посвящено не С++, а психологии человека воспринимающей все новое с очень большой долей скепсиса. А что до скорости, то первые копиляторы С++ были медленее С просто потому, что на них еще не потратили сотни человеколет.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Кодёнок, Вы писали:
Кё>А при чём тут объектно-ориентированные средства вывода? Что там объектно-ориентированого?
Ну как же? Интксуляция, конечно. Программеру глубоко пофигу, что стоит слева от << (>>), как это реализованно и куда пишет (и пишет ли вообще). ОО решение в чистом виде
Здравствуйте, VladD2, Вы писали:
VD>А что до скорости, то первые копиляторы С++ были медленее С просто потому, что на них еще не потратили сотни человеколет.
Сомнительно, что первые компиляторы С++ вообще были медленнее: они реализовывались как трансляторы C++ -> C.
Alxndr,
> VD> А что до скорости, то первые копиляторы С++ были медленее С просто потому, что на них еще не потратили сотни человеколет. > > Сомнительно, что первые компиляторы С++ вообще были медленнее: они реализовывались как трансляторы C++ -> C.
Это так. Также верно то, что у них была достаточно ощутимая abstraction penalty: использование многих возможностей C++ приводило к замедлению и/или увеличению результирующего кода по сравнению с аналогичными "хэками" C традиционно использовавшимися для тех же целей.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
VD>Беспристрастнее нужно быть. Это сообщение посвящено не С++, а психологии человека воспринимающей все новое с очень большой долей скепсиса. А что до скорости, то первые копиляторы С++ были медленее С просто потому, что на них еще не потратили сотни человеколет.
Не могу сказать, что Turbo C++ 1.0 был быстрее, чем Turbo C 2.0, но и намного медленнее он не был.
Здравствуйте, Alxndr, Вы писали:
A>Сомнительно, что первые компиляторы С++ вообще были медленнее: они реализовывались как трансляторы C++ -> C.
Это самый первый. Да и это не делает код автоматически быстрым. Ведь все С++-ные конструкции нужно эмулировать. А эмуляция зачастую дает плохую производительность.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Это так. Также верно то, что у них была достаточно ощутимая abstraction penalty: использование многих возможностей C++ приводило к замедлению и/или увеличению результирующего кода по сравнению с аналогичными "хэками" C традиционно использовавшимися для тех же целей.
А как же клятвенные заверения Бьярна ("D&E"), что, мол, эффективность не хуже C являлась одной из главных целей?
Можно пример конструкции C++, которая является функциональным аналогом конструкции C, но при этом мы имеем abstraction penalty?
Alxndr,
> ПК> Это так. Также верно то, что у них была достаточно ощутимая abstraction penalty: использование многих возможностей C++ приводило к замедлению и/или увеличению результирующего кода по сравнению с аналогичными "хэками" C традиционно использовавшимися для тех же целей.
> А как же клятвенные заверения Бьярна ("D&E"), что, мол, эффективность не хуже C являлась одной из главных целей?
У Бьярна речь шла о возможности эффективной реализации. В прошлом далеко не все компиляторы это делали.
> Можно пример конструкции C++, которая является функциональным аналогом конструкции C, но при этом мы имеем abstraction penalty?
Еще раз напоминаю, что речь об abstraction penalty шла в прошедшем времени. Примеры простые: макросы vs. inline функции и шаблоны, исключения vs long jumps/коды возврата и т.п. На современных компиляторах уже давно все в порядке.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Не могу сказать, что Turbo C++ 1.0 был быстрее, чем Turbo C 2.0, но и намного медленнее он не был.
Главное, что они оба намного медленее чем VC 7+ или Intel C++ 9.0.
Кстати, продукты линейки Турбо вообще небыли рассчитаны на оптимизацию кода. Они больше ориентировались на скорость разработки и интеграцию с IDE. У МС тоже был QuickC который просто таки летал на ХТ-ихах, но порождал очень медленный код по сравнению с МС С 5/6.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Это так. Также верно то, что у них была достаточно ощутимая abstraction penalty: использование многих возможностей C++ приводило к замедлению и/или увеличению результирующего кода по сравнению с аналогичными "хэками" C традиционно использовавшимися для тех же целей.
Именно. И тоже самое ожидает упрвляемые среды (дотнет и Яву). Надеюсь, что разссказывать о разных escape analysis, размещение лаокальных объектов в стеке, спекулятивном устранении виртуальности и т.п. не надо? Это все сложные и трудоемкие задачи. Но они более чем реальны. Так что это просто вопрос времени.
Сан этим уже занимается на полных парах. МС, думаю, тоже. Возможно просто как всегда замах шире, вот и времени уходит больше. А может Сан подталкивает то, что в Яве нет структу, родных для джита дженериков, и без очень глубинных оптимизаций устранить тормоза связанные с ними неудастся. В общем, как бы то ни было, но похоже уже в 6-ке многих кто думает, что Ява лузер (с точки зрения скорости) ждет большой сюрприз.
Собственно прогрес и так на лицо. В 1996 большинство даже поверить не могло, что тормозная Ява будет работать так как она работает сейчас. Ей прочили роль скриптов.
Ну, а то что такие задачи как оптимизация должен делать компьютер, думаю, понимают очень многие...
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>У Бьярна речь шла о возможности эффективной реализации. В прошлом далеко не все компиляторы это делали.
+1
Собственно сегодня очень похожие вещи говорят о джитах. И как обычно рекция точно такая же.
ПК>Еще раз напоминаю, что речь об abstraction penalty шла в прошедшем времени. Примеры простые: макросы vs. inline функции и шаблоны, исключения vs long jumps/коды возврата и т.п. На современных компиляторах уже давно все в порядке.
Ну, не скажи. Если использовать С++ как ООЯ, то прийдется ипользовать такие вещи как множественное виртуальное наследование (приводящее к распуханию указателей и усложнению вычисления адреса), виртуальные методы (приводящие к косвенным вызовам которые сбивают блоки предсказания ветвления в процессорах) и т.п. На С же ты волен сам эмулировать ООП как тебе нравится, а то и вообще не использовать его. Не трудно создать пример на котором красивый ОО-код написанный на С++, даже на самом современном компиляторе, окажется медленее С-шного кода написанного в грязной сишной манере (свитчи, готу, хакерская адресная арифметика...). Конечно можно парировать, что мол "на С++ можно так же", но какой тогда к черту это С++? Можно так же сказать, что есть хаки нового поколения (шаблоны с обратным наследованием и приведениями к указателям на классы-потомки и т.п.), но это опять таки хаки. Код они явно не упрощают.
Забавно, что спекулятивное устранение виртуальных вызвов описано не в одной научной работе и даже проверено на практике, но задача столь сложна в реализации, что нет ни одного промышленного компилятора реализующего эту фичу. Ну, да может здесь опять таки играет роль то, что "если что всегда можно написать по С-шному", так что потребность в таких оптимизациях не так велика как в случае управляемых языков пологащихся всецело на ООП.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2 wrote: > > Кстати, продукты линейки Турбо вообще небыли рассчитаны на оптимизацию > кода. Они больше ориентировались на скорость разработки и интеграцию с > IDE. У МС тоже был QuickC который просто таки летал на ХТ-ихах, но > порождал очень медленный код по сравнению с МС С 5/6.
Я в свое время не поленился отбенчмаркать TC 2.0 vs MSC 5.1 на каком-то
реальном кусочке кода. Разница была совсем небольшая. Ну, может,
процентов 10-20. Не то, что можно заметить невооруженным взглядом...
Здравствуйте, Pzz, Вы писали:
Pzz>Я в свое время не поленился отбенчмаркать TC 2.0 vs MSC 5.1 на каком-то Pzz>реальном кусочке кода. Разница была совсем небольшая. Ну, может, Pzz>процентов 10-20. Не то, что можно заметить невооруженным взглядом...
Ну, вот сейчас между дотнетом и VC7 те же 20 проценов. Можешь поглядеть на отношение С++-ников. К тому же в случае С++ дело упирается в то что в нем появились ОО-фичи вроде виртуальных методов и т.п. Так вот по началу они "торомозили" довольно заметно.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2 wrote:
> Ну, вот сейчас между дотнетом и VC7 те же 20 проценов. Можешь > поглядеть на отношение С++-ников. К тому же в случае С++ дело > упирается в то что в нем появились ОО-фичи вроде виртуальных методов и > т.п. Так вот по началу они "торомозили" довольно заметно.
Здравствуйте, Cyberax, Вы писали:
>> Ну, вот сейчас между дотнетом и VC7 те же 20 проценов. Можешь >> поглядеть на отношение С++-ников. К тому же в случае С++ дело >> упирается в то что в нем появились ОО-фичи вроде виртуальных методов и >> т.п. Так вот по началу они "торомозили" довольно заметно.
C>По памяти поbenchmark'айте...
Зачем? У кого-то с ней проблемы?
К тому же С++-ные приложения тех лет тоже по памяти обычно были куда прожорливее. Ведь ООП к этому подталкивал.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Ну и в особые минуты проглядываю. И видел я на сайте сообщения, гласящие: "подобно этому, в стародавние времена говорили подобным образом о кое-чем" (не будем уточнять). Но фактов не видел. Так вот:
