Тупизмы в C#

Изучаю тут C# (углубленно )

И с самого начала начал натыкаться на некоторые нелогичности в языке.

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

1. byte a, b, c;
2. a = 5;
3. b = 10;
4. c = a + b;

Это не баг, это документированная особенность языка.

Не могу знать! И понять!

Маразм. Впрочем, чего от "продукта" M$ ожидать-то?

Кретинизм. Хорошо хоть я продукт тов. Вирта употребляю.

Дык какбытонибыло... всё равно для типичных юзверьских приложений останется мантра "интерфейс создаём вижуал дизайнером, код пишем на С++, критичые по скорости подпрограммки - пишем и отлаживаем на С, потом переписываем на ассемблер" ...

Сугубое, двугубое и многогубое ( © Куприн ) ПМСМ, разумеется.

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

>Это в котором End то с точкой, то с точкой с запятой употребляется и отсутствуют функции с переменным числом параметров?

Это в котором твой пример записывается:

var a, b, c : byte;

a := 5;
b := 10;
c := a + b;

И КОТОРЫЙ РАБОТАЕТ ВСЕГДА!

>Ну а про то, какой код генерируют компиляторы Паскаля, мы тихо и скорбно помолчим...

Чудесный код они генерируют.

Вот как выглядит Ромин пример:

mov al,$05
mov dl,$0a
lea ebx,[edx+eax]

Думаете Це сгенерирует код лучше?

ЗЫ Мой компилятор хотел этот пример вообще заоптимизировать - выбросить этот явно бессмысленный и неиспользуемый кусок кода. Поэтому приходится находить переменной с применение - например выводить значение на экран и т.п.

Vale>Дык какбытонибыло... всё равно для типичных юзверьских приложений останется мантра "интерфейс создаём вижуал дизайнером, код пишем на С++, критичые по скорости подпрограммки - пишем и отлаживаем на С, потом переписываем на ассемблер" ...

Э... Даже сейчас "пишем и отлаживаем на C" - это процентов 5 проектов, "переписываем на ассемблер" - доли процента, хорошо, если сотые

Как я показывал тут в бенчмарктестах на этом же форуме:
— Скорость исполнение вычислительного кода на C# практически на одном уровне с C++ и уступает только O'Caml (ну, или чему-то типа SP-Forth, если оптимизатор хорошо сработает).
— Скорость работы лобовых решений на Ассемблере ниже, чем таких же решений на ЯВУ. Уже давно перешагнули уровень сложности процессоров, при которой качественный компилятор, в среднем, оптимизирует лучше, чем человек. В конце концов - это дело машины считать такты ИМХО, не за горами и тот день, когда код будет создаваться вообще с участием чего-нибудь подобного генетическим алгоритмам и человек тут окажется уже совсем за бортом.
— Упрощение написания программ путём повышения уровня компилятора позволяет не только писать на порядки более короткий и читабельный код но, из-за этого, зачастую, и более быстрый. Простой пример - предположим, что у нас нет базовых библиотек и нужно самому писать сортировку произвольных типов. На C/C++ на скорую руку будет выдано что-то типа сортировки пузырьком. И это будет с десяток строк кода. На OCaml в одну-две строки пишутся всякие qsort, втавками и т.п., которые работают просто на порядок быстрее. Даже если бы компилятор O'Caml генерил менее быстрый код, чем C++ (что не так), то в итоге мы бы получили выигрышь как по скорости разработки, так и по скорости выполнения конечного кода. C# тут, конечно, смотрится несколько хуже OCaml, но у него и заточка под несколько иное. И, в любом случае, при сопоставимой с C++ скорости, он смотрится намного лучше за счёт гораздо более мощного языка

TEvg>Вот как выглядит Ромин пример:
TEvg>mov al,$05
TEvg>mov dl,$0a
TEvg>lea ebx,[edx+eax]
TEvg>Думаете Це сгенерирует код лучше?

Любой современный CPP-компилер генерит подобное:

1. .
2.   00000 6a 0f        push    15         ; 0000000fH
3. [...]
4.   00007 e8 00 00 00 00   call    _printf

Жень, вот Паскаль у меня ещё в тестах не был

Хочешь "померяемся"?

1. 42-е число Фибоначчи рекурсивным методом. Т.е. fib(n) =
if n
2. Функция Аккермана от 3,8,8.


Или, если так нагляднее, то на c++

1. #include <stdio.h>
2.  
3. int ackr(int n, int x, int y)
4. {  
5.     if(!n)
6.         return x+1;
7.  
8.     if(y)
9.         return ackr(n-1,ackr(n,x,y-1),x);
10.    
11.     switch(n)
12.     {  
13.         case 1: return x;
14.         case 2: return 0;
15.         case 3: return 1;
16.     }
17.     return 2;
18. }
19.  
20. void main(void)
21. {  
22.     printf("%d\n",ackr(3,8,8));
23. }

Давай, напишешь и скомпилишь их под Паскаль и приаттачишь exe-шники сюда. Я же приаттачу версии на O'Caml, VC7 и C#

Хочешь?

TEvg>mov al,$05
TEvg>mov dl,$0a
TEvg>lea ebx,[edx+eax]

Скромные вопросы:
1. Что будет с этим кодом, если на входе в ah или dh что-то будет?
2. Зачем для вычисления суммы двух констант обирать ТРИ регистра? У нас что, RISC с 32-мя регистрами общего назначения?

Кстати, Жень, за функцию Аккермана сразу не берись, ты в Паскале, ИМХО, так легко ~400Мб под стек не выделишь

Давай сразу 42-е число Фибоначчи.

1. #include <stdio.h>
2.  
3. int fib(int n)
4. {
5.     return n<2 ? 1 : fib(n-1)+fib(n-2);
6. }
7.  
8. void main(void)
9. {
10.     printf("%d",fib(42));
11. }

Вот для тестов и сравнений аттач рекордсмена - программы на SP-Forth 4

У меня оно считает 5 сек.

Вот почти не уступающий ему пример на O'Caml (тоже 5.0 сек, но в сотых обычно чуть уступает Forth'у)

А, фиг с ним. Лови все

VC7 - 5.6сек
C# - 6.6сек в MS'овском JIT и 5.4 сек в JIT mono

Фиббоначи, 42-е число:

function fib(n:byte):integer;
begin
if n<2 then
Result:=1 else Result:=fib(n-1)+fib(n-2);
end;

генерируемый код:

push ebx
push esi
mov ebx,eax
cmp bl,$02
jnb fib + $11
mov eax,$00000001
pop esi
pop ebx
ret

Результат - 433.494.437
Израсходовано тактов проца - 863.031.753 - замеряно по RDTSC

Проц AMD XP 1400 МГц

Винда 2000-я многозадачная из-за чего количество тактов все время было разное, но не более чем на 1%.

>1. Что будет с этим кодом, если на входе в ah или dh что-то будет?

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

>2. Зачем для вычисления суммы двух констант

Это не константы - это переменные. Паскаль - язык строгий.

>обирать ТРИ регистра? У нас что, RISC с 32-мя регистрами общего назначения?

?? Мне не жалко. Что у меня в проце регистров нет чтоль?

TEvg>генерируемый код:
TEvg>push ebx
TEvg>push esi
TEvg>mov ebx,eax
TEvg>cmp bl,$02
TEvg>jnb fib + $11
TEvg>mov eax,$00000001
TEvg>pop esi
TEvg>pop ebx
TEvg>ret

Это, как минимум, не весь код.
Хотя бы потому, что в этом коде нет метки fib и непонятно, куда идёт переход.

TEvg>Результат - 433.494.437
TEvg>Израсходовано тактов проца - 863.031.753 - замеряно по RDTSC

Ты exe-шник приложи. Зазипуй - и в аттач.

>>1. Что будет с этим кодом, если на входе в ah или dh что-то будет?
TEvg>Чукча умный, чукча не дурак. Компилятор все учитывает.

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

TEvg>Это не константы - это переменные.

Гм. Если 5 и 10 - это переменные, то опаньки

TEvg>?? Мне не жалко. Что у меня в проце регистров нет чтоль?

У тебя их всего четыре чистых РОН и два, которые таковыми можно назвать условно. Это ОЧЕНЬ мало. Сравни с 16..32 регистрами на почти любом RISC и даже с 8 практически равноправными регистрами архитектуры DEC 30-летней давности Основная проблема оптимизации - это именно оптимальное распределение регистров. И если на простую операцию их требуется аж три, то ни о какой глобальной оптимизации и речи быть уже не может.

Хотя, повторюсь, любой нормальный компилятор в этом примере с суммой байт не при исполнении считать их будет, а при компиляции. И это уже лет эдак с 5..7

>Это, как минимум, не весь код.
>Хотя бы потому, что в этом коде нет метки fib и непонятно, куда идёт переход.

Это начинка процедуры, оттуда куда кидает управление call и до ret.

>Ты exe-шник приложи. Зазипуй - и в аттач.

Аллах.. ладно в понедельник.. ты лучше такты посчитай по RDTSC

>Гм. Если 5 и 10 - это переменные, то опаньки

Именно. Не 5 и 10, а - A,B,C : BYTE;
константы пишутся так const a=5, b=10;

>И если на простую операцию их требуется аж три, то ни о какой глобальной оптимизации и речи быть уже не может.

На Фиббоначах он же хороший код построил?

Товарищ Balancer, а исходный текст программы - fib42_spforth4.zip
- на форте можно увидеть (для общего развития)?

TEvg>Израсходовано тактов проца - 863.031.753 - замеряно по RDTSC
TEvg>Проц AMD XP 1400 МГц

При рекурсивном вычислении fib(42) происходит 866988873 вызовов функции. Хочешь сказать, что на одну итерацию у тебя уходит 863031753/866988873 = 1.00 такт?? На два вычитания, сложение, организацию вложенного вызова?