Файлы JPEG несут угрозу ПО Microsoft

 
1 2 3
+
-
edit
 

Balancer

администратор
★★★★☆
И, вот. Чтобы было неповадно сравнивать C# с VB.NET
Сделал пример на VB - считает 4 минуты.
Прикреплённые файлы:
fib42_vb.zip (скачать) [1,54 кбайт, 17 загрузок] [attach=27029]
 
 
 
+
-
edit
 

Balancer

администратор
★★★★☆
Реконструктор>Во-первых, вот настоящий боксинг, вполне реальная ситуация. Видел такие, подобное иногда творят пришельцы из безтипных языков, типа ПХП.

Кстати. Подумалось тут, что тебе будет интересно. Рекордсмен по этому тесту, OCaml, если тебе лениво качать исходник, чтобы глянуть, считает Фибоначчи, например, так:

let rec fib n =
  if n < 2 then 1 else fib(n-1) + fib(n-2) ;;


Поищи тут хоть одно упоминание типа :D

А если типы не по явному указанию компилятору, то в PHP типы есть :) Только они прозрачно для пользователя преобразуются друг в друга и RTTI :)
 
RU Centuriones #18.09.2004 11:01
+
-
edit
 

Centuriones

опытный

Создается впечатление, что в "дырах" главная вина лежит в передаче значений (массивов) через стек? Кстати, что такое "хийп"?
Раньше были времена,
А теперь мгновения.
Раньше поднимался дух,
А теперь давление.
 
RU Balancer #18.09.2004 11:20  @Centuriones#18.09.2004 11:01
+
-
edit
 

Balancer

администратор
★★★★☆
Centuriones>Создается впечатление, что в "дырах" главная вина лежит в передаче значений (массивов) через стек?

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

Centuriones>Кстати, что такое "хийп"?[»]

heap? "куча". Обычно под эти понимают всю память, которая может быть выделена приложению. Т.е. приложение для своих нужд - создания массивов, объектов и т.п. во время своей работы, заказывает память у операционной системы. Когда память перестаёт быть нужна - возвращает.
 
+
-
edit
 

Balancer

администратор
★★★★☆
tarasv> Надо сказать что для вычисляторных задач мастдай а для коммерческих с БД какраз плюсы мастдай и ИМХО гораздо более полный чем жаба или сишарп для вычисляторных.[»]

Даже для чистой воды вычислительных задач C# обычно оказывается выгоднее С++, если учесть время разработки.

Помню тут на Авиабазе решали задачку с прыгающим мячиком. Кто-то аналитически решал, а я взялся попробовать комбинаторно, численно, т.к. нынешние выч. мощности позволяют :)

На Perl программа считала бы несколько суток (пусть и пишется за 20 минут). На C++ я бы сутки программу писал бы (всякие массивы массивов, ассоциативные массивы и т.п.) На C# я программу написал и отладил за час, наверное. Посчитала она задачу за несколько часов. И что толку, если бы на C++ задача решалась бы не 6, скажем, а 5 часов, но я бы сутки лишние затратил на написание программы? :)
 
RU Centuriones #18.09.2004 11:55
+
-
edit
 

Centuriones

опытный

Я то все как-то пишу на Фортране... Си, Си++ совсем не знаю.
Раньше были времена,
А теперь мгновения.
Раньше поднимался дух,
А теперь давление.
 
RU Сын советского программиста #18.09.2004 13:41  @Реконструктор#17.09.2004 16:43
+
-
edit
 
Во-первых, вот настоящий боксинг, вполне реальная ситуация. Видел такие, подобное иногда творят пришельцы из безтипных языков, типа ПХП.
code text
  1. int fib(object n)
  2. {
  3.         int N = (int)n;
  4.         if (N < 2)
  5.         {
  6.                 return 1;
  7.         }
  8.         else
  9.         {
  10.                 return fib(N-1) + fib(N-2);
  11.         }
  12. }

[»]
 

Неудачный пример. Здесь основные тормаза создает рекурсия, а не преобразование типов. А еще точнее сочетание рекурсии и преобразования.
Я рекурсию не люблю и не использую, только в редких случаях можно оправдать ее использование.

Реконструктор>На фиб(40):
Реконструктор>C++ : 2.7 сек
Реконструктор>C# : 33.9 сек
Реконструктор>Так что разница более чем порядок.
Похоже, что ты не включил оптимизацию ;)

Реконструктор>И под конец, фунция без боксинга (т.е. int fib(int n)) дает 27.1 сек. т.е. не слишком быстрее боксинга. :)
Как раз из-за рекурсии. :)

Реконструктор>Вывод: Ц# мастдай. Игрушка для юношей. И хватит тебе всякую чепуху защищать. :)
Зачем рубить с плеча. Это инструменты для задач разных классов.
С# - время разработки и очень высокая переносимость, в ущерб скорости программы
С - крутой макроассемблер - обратная противоположность С#
С++ - на пути от С к C# :)
А способность выбрать нужный инструмент как раз и отличает мастера от юноши B)

ЗЫ
И не думайте, что в Союзе небыло языков высокого уровня. :) В начале 90-х проектировался язык еще более мощный чем C#, с жесткими требованиями по быстродействию и компактности кода. B) Но... пришла демократия... :ph34r:
Сын советского программиста  
+
-
edit
 

Balancer

администратор
★★★★☆
С.с.п.>Неудачный пример. Здесь основные тормаза создает рекурсия, а не преобразование типов. А еще точнее сочетание рекурсии и преобразования.

Как раз пример более-менее реальной сильно декомпозированной задачи. См. на рекурсию не как на рекурсию, а как на многочисленные функциональные вызовы :)
 
+
-
edit
 

Balancer

администратор
★★★★☆
Ну, вот, совсем уже чистейшая математика :)
C# - [b]7.2[/b]сек [показать]


C++ - [b]7.0[/b]сек [показать]


Т.е. на голой математике разница становится совсем пренебрежимой :)
 
BG Реконструктор #18.09.2004 18:03
+
-
edit
 
Роман, откуда ты такие цифры береш!? :blink: Или опять измеряеш интервал перед и после запуска .ехе-шника? :)

Вот мои данные:
32.3 C#
21.7 C++

Проц - Атлон 950 (однако мне кажется, что я его разогнал до 1000) Проигрыш C# составляет более 30%. Очень и очень серезная цифра.
Вот ПРАВИЛЬНЫЙ код, т.е. такой, который сам измеряет время:
Прикреплённые файлы:
sum_test.zip (скачать) [32,15 кбайт, 18 загрузок] [attach=27033]
 
 
 
RU Balancer #18.09.2004 18:16  @Реконструктор#18.09.2004 18:03
+
-
edit
 

Balancer

администратор
★★★★☆
Реконструктор>Роман, откуда ты такие цифры береш!? :blink:

Уж какие есть. Сейчас рассмотрю твои примеры подробнее.

Реконструктор>Или опять измеряеш интервал перед и после запуска .ехе-шника? :)

И что не так?
Вот твоя цифра: 6969
Вот моя: 00:00:07.000

0.4% - это большая погрешность? :D
Так что мерить я уж внешним таймером буду.

Итак, твой вариант C++ работает 7.0 секунд. Что тобой компилированный, что мной.

Вариант на C#, скомпилированный тобой у меня работает те же 7.03сек. на MS .NET Framework и 20.3 секунды на Mono. Может, ты под Mono запускаешь? :D

Сам же скомпилировать не смог, т.к. ты построил совершенно некомпилябельный с консоли проект. Но цифры ты сверху видел :)

Реконструктор>Вот ПРАВИЛЬНЫЙ код, т.е. такой, который сам измеряет время:[»]

В общем, стабильно воспроизводимые твоим кодом цифры - 7.016 сек. для C++ и 7.031 для C#

(Вариант с 6.969 - это из которого выкинут getch, чтобы программа сама завершала работу. Нафига эту муть в конце ставить?)

Upd: процессор - Prescott, 3.2ГГц
 
+
-
edit
 

Balancer

администратор
★★★★☆
Да, если символ направить через буфер обмена в оригинальный вариант, то твои цифры выходят 7.062 против "моих" (через внешнюю измерялку) 7.031 - так что вопрос о точности измерения времени работы через плагин timer: в FAR'е, считаю, можно закрыть :)
 
RU Centuriones #18.09.2004 19:30  @Сын советского программиста#18.09.2004 13:41
+
-
edit
 

Centuriones

опытный

С.с.п.>ЗЫ
С.с.п.>И не думайте, что в Союзе небыло языков высокого уровня. :) В начале 90-х проектировался язык еще более мощный чем C#, с жесткими требованиями по быстродействию и компактности кода. B) Но... пришла демократия... :ph34r:[»]

А что это было?

Раньше были времена,
А теперь мгновения.
Раньше поднимался дух,
А теперь давление.
 
RU Сын советского программиста #19.09.2004 00:28  @Сын советского программиста#18.09.2004 13:41
+
-
edit
 
С.с.п.>>ЗЫ
С.с.п.>>И не думайте, что в Союзе небыло языков высокого уровня. :) В начале 90-х проектировался язык еще более мощный чем C#, с жесткими требованиями по быстродействию и компактности кода. B) Но... пришла демократия... :ph34r:[»]
Centuriones>А что это было?[»]
Это можно назвать САПР программного обеспечения. Знаю, что в рамках этих разработках был создан генератор ядра операционной системы. Разрабатывался мощный машино независимый ЯВУ, генераторы программ обмена и др. Дальнейшие разработки после развала естественно были остановленны.
Сын советского программиста  
RU Сын советского программиста #19.09.2004 00:32  @Balancer#18.09.2004 15:03
+
-
edit
 
Balancer>Как раз пример более-менее реальной сильно декомпозированной задачи. См. на рекурсию не как на рекурсию, а как на многочисленные функциональные вызовы :)[»]
А о чем тогда вы спорите, кто быстре функции вызывает? :) Дык, одинаково должно быть, и математика тоже. :huh:
И что такое тогда "боксинг"?

Сын советского программиста  
RU Balancer #19.09.2004 00:39  @Сын советского программиста#19.09.2004 00:32
+
-
edit
 

Balancer

администратор
★★★★☆
С.с.п.>А о чем тогда вы спорите, кто быстре функции вызывает? :) Дык одинаково должо быть. :huh:

Нет. Методы формирования фреймов стека, передача параметров, оптимизация вызовов - это всё сильно разнится у разных реализаций. См. цифры по скорости :)

С.с.п.>И что такое тогда "боксинг"?[»]

В C# все классы, в т.ч. int являются наследниками базового класса object и могут быть приведены к нему. Это boxing. Соответственно, и базовый object может быть приведён к конкретным классам - это uboxing. Что-то типа приведения указателей разных типов к void* а наоборот в C++ :)
 
RU Сын советского программиста #19.09.2004 00:46
+
-
edit
 
Balancer>Нет. Методы формирования фреймов стека, передача параметров, оптимизация вызовов - это всё сильно разнится у разных реализаций. См. цифры по скорости :)
Ну так цифры такиеже получаются ;)

Balancer>В C# все классы, в т.ч. int являются наследниками базового класса object и могут быть приведены к нему. Это boxing. Соответственно, и базовый object может быть приведён к конкретным классам - это uboxing. Что-то типа приведения указателей разных типов к void* а наоборот в C++ :)
Понятно. Только вот, не вижу в этом ничего криминального - приводящего к замедлению программы. :)
Сын советского программиста  
RU Balancer #19.09.2004 01:12  @Сын советского программиста#19.09.2004 00:46
+
-
edit
 

Balancer

администратор
★★★★☆
С.с.п.>Ну так цифры такиеже получаются ;)

Там, где с вызовами - нет :)
4.6, 5.3 и 6.3 сек - разница немалая :)

С.с.п.>Понятно. Только вот, не вижу в этом ничего криминального - приводящего к замедлению программы. :)[»]

Нужно в реальном времени определять тип объекта. Это ж, именно, не смена типа указателя на этапе компиляции, а реалтаймовый процесс. Так что падение скорости в 3...6 раз - это очень хорошо и енмалое достижение :)

Кстати, по чистому вычислению без вызовов - вот и попался случай, где OCaml проиграл не только C++, но и C#. На циклах с подсчётом суммы у него получилось 8.6сек. Впрочем, можно понять - язык функциональный, императивщина у него как костыль и вряд ли оптимизируется хорошо.
 
RU Сын советского программиста #19.09.2004 15:43
+
-
edit
 
Balancer>Там, где с вызовами - нет :)
Balancer>4.6, 5.3 и 6.3 сек - разница немалая :)
На С/С++ вызовы, точнее передача аргументов, поразному может быть ограгизована. Передача через регистры, ясный бубен, самая быстрая :)
А какие варианты в C# и OCaml?

Balancer>Нужно в реальном времени определять тип объекта. Это ж, именно, не смена типа указателя на этапе компиляции, а реалтаймовый процесс.
Ну для "больших" объектов да, а для простых типов, помоему, должно быть тоже самое, их преобразование выполняли еще и в ассемблерные времена :)
Сын советского программиста  
+
-
edit
 

Balancer

администратор
★★★★☆
С.с.п.>На С/С++ вызовы, точнее передача аргументов, поразному может быть ограгизована. Передача через регистры, ясный бубен, самая быстрая :)

Естественно, компиляция идёт с ключиком /Gr :)
Если бы передача параметров шла через стек, то проигрышь бы был уже не на проценты, а в разы.

С.с.п.>А какие варианты в C# и OCaml?

OCaml - тоже через регистры. C# - сие зависит от фреймворка, поскольку в MSIL регистров, кажется, вообще нет. Только стеки.

С.с.п.>Ну для "больших" объектов да, а для простых типов, помоему, должно быть тоже самое

Определение типа от размера не зависит :)
 
RU Сын советского программиста #19.09.2004 16:25  @Balancer#19.09.2004 16:10
+
-
edit
 
Balancer>Естественно, компиляция идёт с ключиком /Gr :)
Balancer>OCaml - тоже через регистры.
Ок.

Ром, просвети, насколько я знаю C# транслируется в промежуточный машиннонезависимый язык. А уже во время выполнения на конкректном компе подставляется нужный код, так? Вероятно, где возможно генерируется передача аргументов через регистры... И еще, что такое - "фреймворк"?
А то я в последнее время вынужден занимать языками низкого уровня, малек отстал от развития ЯВУ, совсем немного :)

Balancer>Определение типа от размера не зависит :)[»]
Под словом "большой" подрузамивалось сложность преобразования одного типа к другому. Понятно, что большие объекты будут иметь тенденцию к усложнению преобразованию типов, хотя могут быть и исключеня.


Сын советского программиста  
BG Реконструктор #20.09.2004 10:26
+
-
edit
 
Блин, сейчас этот тест на работе запустил, потрясающе! По моему, конспирация Интеля и М$! Времена, соответсвено:
8.969 C#
8.922 C++
Не могу никак понять почему на АМД-шнике такая разница?
 
BG Реконструктор #20.09.2004 10:30
+
-
edit
 
У меня на работе Пень-четыре, 2.4 гига
 
+
-
edit
 

Balancer

администратор
★★★★☆
С.с.п.>Ром, просвети, насколько я знаю C# транслируется в промежуточный машиннонезависимый язык. А уже во время выполнения на конкректном компе подставляется нужный код, так? Вероятно, где возможно генерируется передача аргументов через регистры...

Именно так.

С.с.п.>И еще, что такое - "фреймворк"?

.NET Framework - среда исполнения, в которой работают .NET программы. В виде реализации от MS. Есть ещё, как минимум, две среды. mono и DotGNU. Второй работает медленно и проект полуживой, а вот первый - вполне приличная реализация, позволяющая запускать .NET-программы на Win32, Linux, MacOS, Netware и т.п.
 
RU Balancer #20.09.2004 11:23  @Реконструктор#20.09.2004 10:26
+
-
edit
 

Balancer

администратор
★★★★☆
Реконструктор>Не могу никак понять почему на АМД-шнике такая разница?[»]

Настолько разная оптимизация, видимо, под эти процессоры :)
Пощупай Mono - может, он на AMD шустрее будет.
 
1 2 3

в начало страницы | новое
 
Поиск
Настройки
Твиттер сайта
Статистика
Рейтинг@Mail.ru