Почему INT медленнее NUMBER ?

[Swer]

Здравствуйте , сделал такой тест

package  {
 
import flash.display.MovieClip;
import flash.utils.getTimer;
import flash.text.TextField;
import flash.events.MouseEvent;
 
	public class doc extends MovieClip {
		var tf:TextField;
 
		public function doc() {
stage.color = 0x333333 ;tf = new TextField;tf.textColor = 0xFFFFFF;tf.width = 1000;tf.wordWrap = true;
            stage.addEventListener(MouseEvent.MOUSE_DOWN,m_down);
		}
function m_down(event:MouseEvent):void{
	test();
}
function test():void{
tf.text = "";
addChild(tf);
var i:uint = 0;
var l:uint = 99999999;
var t:uint;
var n1:Number = 567567;
var n2:Number = 434574;
var n3:Number;
t  = getTimer();
 while( i < l ){
	//n3 = n1/(((n1/n2*n2+n2-n2)/n1)*n1);
	 n3 = n1/n2*n2+n2-n2;
	 i++;
 }
 
t = (getTimer()-t);  tf.text = "NUMBER..."+t;
i = 0;
var u1:uint = 567567;
var u2:uint = 434574;
var u3:uint;
t  = getTimer();
 while( i < l ){
	//u3 =  u1/(((u1/u2*u2+u2-u2)/u1)*u1);
	u3 = u1/u2*u2+u2-u2;
	 i++;
 }
t = (getTimer()-t);
tf.appendText( "\n"+"UINT.........."+t);
 
i = 0;
var i1:int = 567567;
var i2:int = 434574;
var i3:int;
t  = getTimer();
 while( i < l ){
	// i3 = i1/(((i1/i2*i2+i2-i2)/i1)*i1);
	 i3 = i1/i2*i2+i2-i2;
	 i++;
 }
t = (getTimer()-t);
tf.appendText( "\n"+"INT............."+t );
 
 
 
}
	}
 
}

Результаты :
NUMBER...271
UINT........689
INT..........469
Но если в циклах раскоментировать верхнюю строку и закоментировать нижнюю :
NUMBER...257
UINT........2222
INT..........2173

Почему такие результаты ? разве int не быстрее Number ?

[amesqit]

Во первых элементарные типы они не бестрее и не медленее, дело скорее в объеме занимаемой памяти. Вот цитата из документации "В типе данных Number для представления целых значений может отводиться до 53 бит в отличие от типов данных int и uint, для которых отводится 32 бита". Так же операция деления всегда возвращает тип Number, поэтому в результате i3, u3 каждый раз должно происходить преобразование типов с отсечением мантисы числа. Ну и возвращаясь у результатам у меня разницы в результатах такая что я бы ей пренебрег, уж никак не на порядок как у вас:
1 закоменчено n3:Number u3:uint i3:int:
NUMBER...705
UINT........758
INT..........728
2 закоменчено n3:Number u3:uint i3:int:
NUMBER...2538
UINT........2529
INT..........2528
1 закоменчено n3:Number u3:Number i3:Number :
NUMBER...741
UINT........722
INT..........712
2 закоменчено n3:Number u3:Number i3:Number :
NUMBER...2540
UINT........2509
INT..........2517

[undefined]

Так же операция деления всегда возвращает тип Number

Вот интересно, на уровне ассемблера целочисленное умножение и деление (mul/div) и вещественное (fmul/fdiv) - это два разных набора команд с совершенно разным временем исполнения.Неужели в конечном счете всегда используется вещественный вариант?

[Swer]

Сообщение от amesqit

Во первых элементарные типы они не бестрее и не медленее, дело скорее в объеме занимаемой памяти.

Есть такое

Сообщение от Adobe

Среда выполнения Flash обрабатывает типы данных int и uint эффективней, чем Number

Возможно разные показатели могут быть из-за разных процессоров

Сообщение от Adobe

Тип данных int полезен для счетчиков циклов и других ситуаций, когда не требуется число с плавающей запятой. Он аналогичен типу данных int в языках Java и C++.

В C++ вроде как не происходит никакого преобразования из к примеру из float в int там просто незаписываются не нужные байты

[undefined]

действительно приводится к флоту:

var n:int=10;
var m:int=3;
trace(n/m);//3.3333333333333335

[dimarik]

Почему такие результаты ? разве int не быстрее Number ?

Нужно получившийся байткод смотреть.

[alatar]

Сообщение от dimarik

Нужно получившийся байткод смотреть.

В данном случае мешает деление, для которого нет целочисленного аналога в байткоде. Но даже если убрать деление и подобрать формулу, которая не будет давать переполнение для int, компилятор не использует целочисленное умножение и сложение. Если принудительно поменять multiply на multiply_i, а add на add_i, то результат будет немного (пренебрежимо) лучше чем при операциях с Number.
В общем, лучше не заморачиваться.