doza_and

ну, прям в 200 миллионов раз?
Я сделал на вставку FASM и результат 4мс на 10млн операций и я что-то разницу в 200 млн не вижу:
И как 28т может занимать 0,3 нано секунды?
И даже если у вас один цикл программы занимает 28т=0,3 наносек., то 10млн циклов - это 3мс.. что никак не в 200 млн раз быстрее

Procedure test()
StartTime = ElapsedMilliseconds()
!mov ecx,10000000
!xor ebx,ebx
!ll_label:
!inc ebx
!dec ecx
!jnz ll_label
PrintN(“Elapced time:”+Str(ElapsedMilliseconds()-StartTime)+“ms”)
EndProcedure

OpenConsole(“bla-bla”)
test()
Input()

А если поменять колво итераций на порядок, ещё большие чудеса начнутся.

Etayson
И даже если у вас один цикл программы занимает 28т=0,3 наносек

Вы не поняли - все циклы занимают 28 тактов.

Не надо очень серьезно к этому относится.

• Я имел ввиду, что для реальных программ замерять скорость сложения не имеет смысла. В большинстве случаев сейчас скорость выполнения лимитируется совсем не временем выполнения операций.
  
• Замерять надо несколько иначе. Но конечно сильно вы не ошибетесь ну раза в 2 -3
  
• Сравнивать надо одинаковые операции. Что вы получите в данном коде на бейсике?
  

  >>> print(4000000000*4000000000)
  16000000000000000000
  

• Если компилятор имеет хоть минимальное понятие об оптимизации то он выкинет код не влияющий на результат. Это явно не про ваш инструмент.
  

Но вцелом. Используйте то что вам удобно. быстродействие нужно далеко не всегда. Для хороших компиляторов/ интерпретаторов одинаковые действия обычно выполняются примерно за одинаковое время и не важно это C Фортран бейсик или питон.

Бэйсик рулит!