forum.boolean.name - Об использовании Goto

forum.boolean.name (http://forum.boolean.name/index.php)

- FAQ (http://forum.boolean.name/forumdisplay.php?f=15)

- - Об использовании Goto (http://forum.boolean.name/showthread.php?t=26)

у меня goto - 4, for - 6

PS я всегда говорил GOTO - Forever !!

у меня:
goto - 350
for - 95
еcли вырубить debug
goto - 7
for - 4

PS: включённый Скайп, ВинАМП, Аська и скрипт Sign0fMissery

вот еще всем кто говорит что функции рулят, пусть протестят вот этот код:

Код:

ITER=1000000

;====

time1=MilliSecs()

for i=1 to iter

 gosub subprogram

next

time1=MilliSecs()-time1

;===

time2=MilliSecs()

for i=1 to iter

 subprogram()

next

time2=MilliSecs()-time2

;===

time3=MilliSecs()

for i=1 to iter

 goto subprogram1

 .returnsubprogram

next

time3=MilliSecs()-time3



Print "GoTo   "+time3

Print "GoSub  "+time1

Print "Function "+time2

WaitKey()

End



.subprogram

 a=a+1

return



.subprogram1

goto returnsubprogram



function subprogram()

 a=a+1

end function

вот пример вызова функции, подпрограммы и простого перехода... протестите что быстрей! ;) :rolleyes: :rolleyes:

GoTo и GoSub рулят :super: ... вот тока в подпрограммы нельзя посылать параметры :unsure: как в функции и с возвратом какого-то значения тоже проблема будет (без допогнительных переменных не обойдешься).

процедурки masm foreva

ps. вывод goto медленее for ТОЛЬКО ПОТОМУ ЧТО В GOTO СТОИТ IF!
вот доказательство

Код:

time2=MilliSecs()

While z=0

If x=ITER Then z=1

x=x+1

Wend

time2=MilliSecs()-time2

print time2

и почему в блице нельзя делать инлайн функций без рекурсии ? :)

impersonalis, не обижайся и не ругайся :lol:
гото всётаки рулят :lol:

а рулит потому что его щитает проц :)

Цитата:

Originally posted by jimon@Nov 13 2005, 01:24 PM
процедурки masm foreva

ps. вывод goto медленее for ТОЛЬКО ПОТОМУ ЧТО В GOTO СТОИТ IF!
вот доказательство

Код:

time2=MilliSecs() While z=0 If x=ITER Then z=1 x=x+1 Wend time2=MilliSecs()-time2 print time2

и почему в блице нельзя делать инлайн функций без рекурсии ? :)

Да мне как-то пофиг насколько быстрее работает отдельностоящее ГоТо.
Именно что мне постоянно говорят: вместо лишнего цикла - я буду проходить по ГоТо с условием. Вот эти товарищи пусть утрутся.

И ещё: кто вам сказал, что компилятор blitz транслирует высокоуровневую команду goto в низкоуровневую команду goto. Ещё не факт, что в байт-коде оно будет выглядеть как ассемблерное ГоТо, а не набор из if-овов.
Мы же обсужаем использование ГоТо в языках высокого уровня, в частности- blitz3d
:P

Цитата:

Originally posted by jimon@Nov 13 2005, 02:00 PM
а рулит потому что его щитает проц :)

Насыщенная реплика. А операции сложения, вычитания - наверно BIOS считает ;)

я же неговорил про + и - :)

кстати гото внатуре непереходит в нискоуровневый код
незабываем как устроен компилятор

а вот гото в bmax 100 проценто рулит - так как транслируется в jmp :)

Цитата:

Originally posted by impersonalis@Nov 13 2005, 02:42 AM
Вот провёл тестик: что быстрее - цикл или переход по GoTo

Код:

ITER=1000000 ;==== time1=MilliSecs() i=ITER .a i=i-1 If i>0 Goto a time1=MilliSecs()-time1 ;=== time2=MilliSecs() For i=ITER To 1 Step -1 Next time2=MilliSecs()-time2 ;=== Print "Goto "+time1 Print "for "+time2 WaitKey() End

Интересно - попробуйте.

Сравнение некорректное. Использование в цикле For...Next шага Step требует от компилятора дополнительного считывания из памяти переменной, эквивалентной Step. Да и число циклов нужно хотя бы на порядок увеличить.

Код:

ITER=10000000

;====

time1=MilliSecs()

i=1

.a

i=i+1

If i<ITER Goto a

time1=MilliSecs()-time1

;===

time2=MilliSecs()

For i=1 To ITER

Next

time2=MilliSecs()-time2

;===

Print "Goto "+time1

Print "for "+time2

WaitKey()

End

Teперь цикл с GOTO выполняется медленнее. (За счет того, что в итоговом ассемблерном коде в цикле For...Next используется константа и прямой инкремент регистра).

P.S. На ассемблере часто вместо прямого перехода jmp addr используется связка типа push .... ret.

Гораздо полезнее посмотреть, насколько медленнее происходит обращение к глобальным переменным, объявив ITER как GLOBAL.....

GOTO в Блитце бывает полезна (очень редко) на коротких фрагментах программы. В одной из полных игровых программ, идущих в комплекте с полной версией Блитц3Д, она используется несколько раз и не ухудшает ни стиля, не читаемости программы. Другое дело, что современный принцип построения программм (в том числе и на ассемблере) - модульный, поэтому это GOTO и GOSUB может быть с трудом оправдано в пределах одного модуля, хотя любой алгоритм позволяет обойтись и без них.
Дополнительные потери времени при использовании функций, связанных с формированием кадра переменных на стеке и его использования, настолько несущественны, что не идут ни в какое сравнение с потерями времени на отладку и модификацию программы при отсутствии модульной структуры.
Разумеется, речь идет не о тесте на скорость, а о нормальной программе.
В таких программах использование GOTO и GOSUB означает только лишь некомпетентность программиста (я не имею в виду старые версии Бейсика, где просто не было полноценных функций).

Цитата:

Originally posted by Guest@Jan 1 2006, 10:47 PM
В таких программах использование GOTO и GOSUB означает только лишь некомпетентность программиста (я не имею в виду старые версии Бейсика, где просто не было полноценных функций).

интересная у вас стратеги товарищ... ИМХО функции и прочую байду придумали для упрощения программирования, с этим я согласен, просто не надо думать, что:

1. функции работают с такой-же скоростью как и прямые переходы
2. тот кто юзает функции типа некомпетентен и в простонароде называется "ламер", по аналогии всех велосипедистов можно было опустить, ведь давно придуманы машины...

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

могу короче представить много глюков с программированием функциями, примерно столько-же по программированию гото'м... здесь главное это алгоритмическое мышление, и реализовать один и тот-же алгоритм можно поразному...

НО единственная плохая черта в вас кодящих функциями, это то, что вы против тех кто кодит с участием ГоТо... а мы ГоТовцы нисколько не против вас...

:)

Прирост от юзания ГоТо в прогах на б3д ( а имеено об этом здесь речь) - б.м. [как выражается alex-mad - "безумно малая величина"], а вот код сильно страдает.
Сдаётся мне, что все разговоры о, якобы, борьбе за скорость выполнения имеют под собой всего лишь не умение мыслиьт абстрактно ( лично, SubZero в виду не имею, т.к. достаточно хорошо знаю его адекватность и умственные способности ).
Хотя ГоТо в отдельных случаях (читай: консольный брутфорсер, написанный с 0 на асме) - это вещь :super: , но не здесь (читай: в офигительно разветвлённом алгоритме, описывающем сложные модели поведения перса и NPC).

по оптимизации кода у меня есть неплохая вырезка из статьи "сравнение производительности КПК и настольных систем"
там человек обяснялся почему он неприменял оптимизацию к коду

Цитата:

Оптимизацию можно условно разделить на 3 вида:

1.Оптимизация машинного кода.

Дело в том, что одну и ту же программу, написанную на языке высокого уровня, в данном случае на С, перевести в машинный код можно множеством способов. Вот простой пример. Допустим нам нужно поместить в регистр AX - ноль. Это можно сделать следующими способами:
1)MOV AX, 0;
2)MOV AL, 0; MOV AH, 0;
3)XOR AX, AX;
4)XOR AL, AL; XOR AH, AH;
5)XOR AL, AL; MOV AH, AL;
6)PUSH 0; POP AX.

Один из этих способов окажется быстрее. Причем, какой именно, зависит от конкретного процессора. Одни процессоры лучше работают с длинными командами, другие с короткими и т.д. А если бы мы выбрали оптимизацию на минимальный размер, то возможно выбрался бы какой-нибудь другой способ. Естественно, в реальных приложениях все много сложнее, т.к скорость выполнения зависит и от окружающих команд. Так же очень сильно на скорость выполнения влияет порядок команд (ведь часто от смены порядка нескольких соседних команд суть кода не меняется).

2. Использование специфических особенностей процессора.

Это, прежде всего, расширенные наборы команд MMX, SSE1-3 и другие (конкуренты Intel тоже не отстают в командотворчестве). Эти команды хороши, но не всесильны. Область их эффективного применения довольно ограничена. Их суть ясна из их общего названия - SIMD (Single Instruction - Multiple Data/Одна инструкция - Много данных). Другими словами, они позволяют выполнить за одну команду какое-либо действие сразу же над несколькими числами. Это достигается за счет того, что данные наборы команд работают со специальными длинными регистрами, в которые можно поместить целый набор чисел - до 16-ти. MMX предназначен для обработки целых чисел и использует регистры сопроцессора (только 64 бита), в то время, как SSE работает с вещественными числами и использует собственные 128-битные регистры. SSE2, SSE3 развивают идеи заложенные в MMX и SSE. Таким образом, данные команды хорошо подходят для алгоритмов, которые выполняют простые, однотипные действия над большим объемом данных. Причем, эти алгоритмы должны иметь поменьше условных переходов, а вычисления можно было бы "распараллелить" (т.е для каждого последующего вычисления не нужно было бы знать результат предыдущего). В качестве примеров таких задач можно привести MPEG-декомпрессию, шифрование, преобразование цветового пространства, наложение текстуры, работу с комплексными числами, быстрое преобразование Фурье, дискретное косинус-преобразование, обсчет 3-х мерных сцен. Это весьма ресурсоемкие задачи, которые постоянно встречаются при работе с мультимедийными данными и играми. Поэтому понятно, почему инженеры Intel ввели в архитектуру процессора механизмы ускорения подобных задач - имеет смысл ускорять то, что выполняется дольше всего. Задачи из моего тестового приложения очень плохо подходят для данного вида оптимизации. В них сплошные условные переходы, размерности массивов задаются переменными, вычисления не распараллеливаются, используются тригонометричекие функции.

3.Оптимизация алгоритма.

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

int a = 1;

for (int i = 0; i < 3; i++) a += i*a;

она может быть оптимизирована, например, следующим образом:

int a = 1;

a+= 0*a;

a+= 1*a;

a+= 2*a;

очевидно второй вариант будет сильно быстрее (этот метод оптимизации называется "развертывание цикла"). А более умный компилятор может вообще заменить эту программку одной строчкой:

int a = 6

или вот еще пример:

int i, j, a = 0;

for (i = 0; i < 10; i++) {

for (j =0; j < 10; j++) {

a += (i*15 + j*20);

}

}

можно оптимизировать, например, так:

int i, j, k, a = 0;

for (i = 0; i < 10; i++) {

k = i*15;

for (j =0; j < 10; j++) {

a += (k + j*20);

}

}

в первом случае имеем 200 операций умножения, во втором всего 110. Соответственно второй вариант сильно быстрее. (Этот метод оптимизации называется "вынос константы из цикла").

Оптимизация алгоритма - потенциально самый эффективный, но сложно реализуемый способ. Тем не менее, компиляторы пишут не один десяток лет и те примеры оптимизаций, которые я привел и даже на порядки более сложные, вполне реальны для современных средств разработки.

ето слабо относится к теме,но - здесь более мение обясняется основные принципы оптимизации при прямой трансляции кода в asm
ето очень косается блицмакса

а вот в блице другое дело - тут код нетранслируется никуда :) он остается как был... только математические выражение упрощаются

тоесть нету смысла судить что выполняется быстрее :)
если бы вместе с кодом заново компилировалась библеотека runtime.dll то тогда бы на разных системах была заметная разница от использования разых методов, а так - пофигу :)

ссылка на статью : http://3dnews.ru/cpu/hpc-vs-pc/index02.htm...plate=print.htm