Very different result
Very different result
If I use FreeBasic's standard library function like PRINT, ABS, SQR the program is twice as slow as when using functions from the crt header (printf, fabs, sqrt). Anyone know why there is such a big different?
Re: Very different result
Which version of fbc are you using? And which compiler switches? When I run this code with fbc -gen gcc -Wc -Ofast I get a small difference (~2%) in favor of the fbc rtl (fbc v1.07.1):
Same with some others I've tested: difference is almost non-existent, much less twice as slow. Can you post how do you measure the timings? Calls per second isn't a good measurement, but raw timings aren't either, so...
Code: Select all
#include once "crt.bi"
dim as single _
a => 3.41!, _
b, c
dim as double _
t1, sum1, t2, sum2
dim as uinteger _
count => 100000000
for _
i as uinteger => 1 _
to count
t1 => timer()
b => sqrt( a ) 'fabs( a )
t1 => timer() - t1
sum1 +=> t1
next
c => b
for _
i as integer => 1 _
to count
t2 => timer()
b => sqr( a ) 'abs( a )
t2 => timer() - t2
sum2 +=> t2
next
dim as integer _
cps1 => 1.0 / ( sum1 / count ), _
cps2 => 1.0 / ( sum2 / count )
? "crt calls per second: " & cps1
? "fbrtl calls per second: " & cps2
? "Difference: " & ( cps2 / cps1 ) * 100.0
? "Result: " & c
sleep()
Re: Very different result
I measured using Unix's time command.
The binary compiled with fbc -O 3 test.bas
p/s: I use the same version as yours.
The binary compiled with fbc -O 3 test.bas
p/s: I use the same version as yours.
Re: Very different result
It's your test. In my test, rebuild with your command it's even slower when build with my fbc -O 3. In any case, the crt version won.paul doe wrote:Which version of fbc are you using? And which compiler switches? When I run this code with fbc -gen gcc -Wc -Ofast I get a small difference (~2%) in favor of the fbc rtl (fbc v1.07.1):
Same with some others I've tested: difference is almost non-existent, much less twice as slow. Can you post how do you measure the timings? Calls per second isn't a good measurement, but raw timings aren't either, so...Code: Select all
#include once "crt.bi" dim as single _ a => 3.41!, _ b, c dim as double _ t1, sum1, t2, sum2 dim as uinteger _ count => 100000000 for _ i as uinteger => 1 _ to count t1 => timer() b => sqrt( a ) 'fabs( a ) t1 => timer() - t1 sum1 +=> t1 next c => b for _ i as integer => 1 _ to count t2 => timer() b => sqr( a ) 'abs( a ) t2 => timer() - t2 sum2 +=> t2 next dim as integer _ cps1 => 1.0 / ( sum1 / count ), _ cps2 => 1.0 / ( sum2 / count ) ? "crt calls per second: " & cps1 ? "fbrtl calls per second: " & cps2 ? "Difference: " & ( cps2 / cps1 ) * 100.0 ? "Result: " & c sleep()
Please note that my code is a recursive for loop iterating from n = 1 to 1000000000 and it took nearly an hour to complete each run on my system with the cpu fan spinning like hell. The final result is always the fbrtl is twice as slow as the crt.
p/s: your code looks weird, I've never seen such syntax before.
Re: Very different result
Do you have the code handy?
Re: Very different result
Not needed. I diagnosed the problem.paul doe wrote:Do you have the code handy?
The problem is in the print to screen part, not the calculating of the sequence.
Free Basic's Print is much slower than crt's printf.
I didn't notice that the Free Basic's Print does print the full number, when crt's printf does not print the full number but only up to certain decimal place.
Without the print to screen part there is nearly no different in execution speed.
p/s: you didn't answer me why your code is so weird!
Anyone know why this code is so weird? I have never see such syntax before:
Code: Select all
#include once "crt.bi"
dim as single _
a => 3.41!, _
b, c
dim as double _
t1, sum1, t2, sum2
dim as uinteger _
count => 100000000
for _
i as uinteger => 1 _
to count
t1 => timer()
b => sqrt( a ) 'fabs( a )
t1 => timer() - t1
sum1 +=> t1
next
c => b
for _
i as integer => 1 _
to count
t2 => timer()
b => sqr( a ) 'abs( a )
t2 => timer() - t2
sum2 +=> t2
next
dim as integer _
cps1 => 1.0 / ( sum1 / count ), _
cps2 => 1.0 / ( sum2 / count )
? "crt calls per second: " & cps1
? "fbrtl calls per second: " & cps2
? "Difference: " & ( cps2 / cps1 ) * 100.0
? "Result: " & c
sleep()
-
- Posts: 783
- Joined: Jul 26, 2018 18:28
Re: Very different result
What is the weirdness?nov79 wrote: Anyone know why this code is so weird? I have never see such syntax before:
Code: Select all
#include once "crt.bi" dim as single _ a => 3.41!, _ b, c dim as double _ t1, sum1, t2, sum2 dim as uinteger _ count => 100000000 for _ i as uinteger => 1 _ to count t1 => timer() b => sqrt( a ) 'fabs( a ) t1 => timer() - t1 sum1 +=> t1 next c => b for _ i as integer => 1 _ to count t2 => timer() b => sqr( a ) 'abs( a ) t2 => timer() - t2 sum2 +=> t2 next dim as integer _ cps1 => 1.0 / ( sum1 / count ), _ cps2 => 1.0 / ( sum2 / count ) ? "crt calls per second: " & cps1 ? "fbrtl calls per second: " & cps2 ? "Difference: " & ( cps2 / cps1 ) * 100.0 ? "Result: " & c sleep()
In Freebasic and VB, wrapping to the next line is allowed using the "_" sign.
The sign "=" and "=>" are the same.
Re: Very different result
Except I'm not from Basic, I'm from C. I have read code of people on this forum and never seen such thing .Xusinboy Bekchanov wrote:What is the weirdness?nov79 wrote: Anyone know why this code is so weird? I have never see such syntax before:
Code: Select all
#include once "crt.bi" dim as single _ a => 3.41!, _ b, c dim as double _ t1, sum1, t2, sum2 dim as uinteger _ count => 100000000 for _ i as uinteger => 1 _ to count t1 => timer() b => sqrt( a ) 'fabs( a ) t1 => timer() - t1 sum1 +=> t1 next c => b for _ i as integer => 1 _ to count t2 => timer() b => sqr( a ) 'abs( a ) t2 => timer() - t2 sum2 +=> t2 next dim as integer _ cps1 => 1.0 / ( sum1 / count ), _ cps2 => 1.0 / ( sum2 / count ) ? "crt calls per second: " & cps1 ? "fbrtl calls per second: " & cps2 ? "Difference: " & ( cps2 / cps1 ) * 100.0 ? "Result: " & c sleep()
In Freebasic and VB, wrapping to the next line is allowed using the "_" sign.
The sign "=" and "=>" are the same.
It looks too cryptic.
Re: Very different result
To clearly distinguish the assignment operator (used for setting) from the equality operator (used for testing), some prefer to use the symbol "=>" for the first and the symbol '=' for the second. The opposite ("=>" for equality operator) is not allowed by FreeBASIC.
Re: Very different result
Mildly amusing coming from someone whose first language is C XD:nov79 wrote:...
It looks too cryptic.
Code: Select all
#include <iostream>
void
whatever()
{
for(
int i = 0;
i < 10;
i++ )
std::cout << "Yay" << std::endl ;
}
int
main(
int argc,
char **argv)
{
int
a = 3,
b, c ;
if( a == 3 )
whatever() ;
}
Re: Very different result
Say, since the thread title is 'Very different result', it may be worth pointing out that, coming from C, there are some things that you should take into account when porting code. For example, this C++ code snippet:
The same syntax in FreeBasic yields a very different result:
That is, the semantics of expressions don't always match 1:1, so you should be very aware of these quirks (so as to avoid a headache or two). There are others too (for example, the for-next behavior of FreeBasic vs C's for() statement)
Code: Select all
#include <iostream>
int
main(
int argc,
char **argv)
{
int
a, b ;
a = b = 3 ;
std::cout << a << std::endl ;
std::cout << b << std::endl ;
}
Code: Select all
dim as integer _
a, b
a = b = 3
? a
? b
sleep()
-
- Posts: 534
- Joined: Dec 02, 2011 22:51
- Location: France
Re: Very different result
Hello Nov79. What I like about FB is its versatility in terms of syntax and programming style. You have the possibility of a syntax close to c, directly c, integrate an assembler syntax, prefer an object style, make macros, or try to define your own keywords (an approach that I tried with lzle) . Without elegance and thoroughness, language can never do all that. Often, what may seem "weird" is related to some of the "spirit" of the language: ease, versatility, and creativity. Having been able to keep all of this while offering object or low level possibilities is a feat of the developers involved in the design, documentation, maintenance and development of that tool.
Re: Very different result
You are not the first to mention this, actually: https://freebasic.net/forum/viewtopic.php?f=3&t=26204nov79 wrote:Not needed. I diagnosed the problem.
The problem is in the print to screen part, not the calculating of the sequence.
Free Basic's Print is much slower than crt's printf.
Are you using Linux or Windows?
Re: Very different result
Thank you.fxm wrote:To clearly distinguish the assignment operator (used for setting) from the equality operator (used for testing), some prefer to use the symbol "=>" for the first and the symbol '=' for the second. The opposite ("=>" for equality operator) is not allowed by FreeBASIC.
When I see the "=>" I immediately think about the arrow function: https://developer.mozilla.org/en-US/doc ... _functions
Many programming languages out there utilize this arrow to do functional programming. I just think functional has come to Free Basic.
I don't like functional programming at all. It's too hard for me.
Last edited by nov79 on Mar 03, 2020 14:23, edited 2 times in total.
Re: Very different result
Thanks to remind me about this.paul doe wrote:That is, the semantics of expressions don't always match 1:1, so you should be very aware of these quirks (so as to avoid a headache or two). There are others too (for example, the for-next behavior of FreeBasic vs C's for() statement)
p/s: I don't know C++, only a small subset of plain C.
Last edited by nov79 on Mar 03, 2020 14:58, edited 1 time in total.