User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Why Avoid BASIC on RPi?

Mon Nov 26, 2018 9:20 pm

jahboater wrote:
Mon Nov 26, 2018 9:01 pm
DavidS wrote:
Mon Nov 26, 2018 8:18 pm
'CLOCK_MONOTONIC_RAW' undeclared
is in <time.h>
What version of gcc, I can not find it in the C99 standard at a quick search, and it is NOT in the <time.h> included in the copy of gcc I am using.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Why Avoid BASIC on RPi?

Mon Nov 26, 2018 9:28 pm

Never mind, I just found it out, and it is useless to non-n*x users as it is not defined by C it is part of glibc 2 and newer, and thus OS specific.

This is one of the portability issues I have mentioned in C, I see things like this all the time, because people make certain assumptions about all platforms some of which do not hold true. Many of the non-standard things are replicated in Win32 gcc ports, and a few others, though they are not in all of them.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

Heater
Posts: 14687
Joined: Tue Jul 17, 2012 3:02 pm

Re: Why Avoid BASIC on RPi?

Mon Nov 26, 2018 9:37 pm

That is annoying but...

If it's not defined in any C standard then it hardly the fault of C now is it?
Memory in C++ is a leaky abstraction .

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Why Avoid BASIC on RPi?

Mon Nov 26, 2018 10:21 pm

Heater wrote:
Mon Nov 26, 2018 9:37 pm
That is annoying but...

If it's not defined in any C standard then it hardly the fault of C now is it?
True true. It is the way the programmers use C, and those things that are available to some in C that are outside the standard, not the language.

I am just trying to figure out how to set the value for the define so that it will work to compile and work correctly without any trouble.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

jahboater
Posts: 5173
Joined: Wed Feb 04, 2015 6:38 pm
Location: West Dorset

Re: Why Avoid BASIC on RPi?

Mon Nov 26, 2018 10:33 pm

DavidS wrote:
Mon Nov 26, 2018 9:28 pm
Never mind, I just found it out, and it is useless to non-n*x users as it is not defined by C it is part of glibc 2 and newer, and thus OS specific.
It is part of POSIX.
From wikipedia:
The Portable Operating System Interface (POSIX) is a family of standards specified by the IEEE Computer Society for maintaining compatibility between operating systems.
It is of course nothing to do with C, except that you can use it via a C library.
In the meantime "man clock_gettime" should tell you all.
It is relatively new, which may explain why its not in time.h if your system is a few years old.
Clock_gettime() offers a choice of sophisticated clocks, with "up to" nano-second resolution.
It is implemented on Linux as a system call (svc).
Last edited by jahboater on Mon Nov 26, 2018 10:58 pm, edited 1 time in total.

ejolson
Posts: 4452
Joined: Tue Mar 18, 2014 11:47 am

Re: Why Avoid BASIC on RPi?

Mon Nov 26, 2018 10:49 pm

DavidS wrote:
Mon Nov 26, 2018 10:21 pm
Heater wrote:
Mon Nov 26, 2018 9:37 pm
That is annoying but...

If it's not defined in any C standard then it hardly the fault of C now is it?
True true. It is the way the programmers use C, and those things that are available to some in C that are outside the standard, not the language.

I am just trying to figure out how to set the value for the define so that it will work to compile and work correctly without any trouble.
Sorry about that. I changed the timing routines to use the newer improved Linux clocks that are guaranteed not to send time backwards after measuring some negative execution times using gettimeofday. For decent sized problems such as the ones in those benchmarks the older timing routines work fine. You can find the older routines in the original Cilk versions of the benchmarks posted here. Or alternatively just paste the following code

Code: Select all

static double tic_time;
void tic() {
    struct timeval tp;
    gettimeofday(&tp,0);
    tic_time=(double) tp.tv_sec + (double) tp.tv_usec * 1.e-6;
}
double toc() {
    struct timeval tp;
    gettimeofday(&tp,0);
    return ((double) tp.tv_sec + (double) tp.tv_usec * 1.e-6)-tic_time;
}
and delete the newer versions of the same functions.
Last edited by ejolson on Mon Nov 26, 2018 10:59 pm, edited 2 times in total.

jahboater
Posts: 5173
Joined: Wed Feb 04, 2015 6:38 pm
Location: West Dorset

Re: Why Avoid BASIC on RPi?

Mon Nov 26, 2018 10:50 pm

DavidS wrote:
Mon Nov 26, 2018 10:21 pm
I am just trying to figure out how to set the value for the define so that it will work to compile and work correctly without any trouble.
You cant just do that, as it needs to be supported by your OS.
Even the old gettimeofday() which clock_gettime() replaced did not provide an equivalent for this monotonic timer.
The clock CLOCK_MONOTONIC_RAW is the raw system hardware clock. It will not be affected by micro adjustments from NTP, and it will of course never go backwards due to daylight saving adjustments. The resolution is probably microseconds on the Pi. It starts at some arbitrary time in the past (probably the boot time).
CLOCK_MONOTONIC is the same, but is subject to micro-adjustments. CLOCK_REALTIME is (like gettimeofday()) the clock on the wall time.

I presume this is RISC OS you are using. You need to find a similar clock on RISC OS and replace calls to clock_gettime with calls to your RISC OS swi.

Its probably only used as a hi-res timer to measure speed or something, so it may not be that crucial.

Sorry, cross posted @ejolson's more useful suggestion, but the info here may be of interest - especially if RISC OS doesn't support gettimeofday() either.

ejolson
Posts: 4452
Joined: Tue Mar 18, 2014 11:47 am

Re: Why Avoid BASIC on RPi?

Mon Nov 26, 2018 11:45 pm

jahboater wrote:
Mon Nov 26, 2018 10:50 pm
Its probably only used as a hi-res timer to measure speed or something, so it may not be that crucial.
That's correct. It is used to measure performance. The code contains logic that says keep timing the same test until 5 seconds have passed, so having a reasonably accurate implementation of the tic and toc routines described above is important.

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Why Avoid BASIC on RPi?

Tue Nov 27, 2018 12:48 am

Ok I figured out what the value of CLOCK_MONOTONIC_RAW is supposed to be, and in most cases it will work to define it as CLOCK_MONOTONIC, so that fixes the issue, and I am as close to a compile as I could expect beings the differences in the environments:

Code: Select all

*make
gcc -std=gnu99 -O3 -ffast-math -Wall -lm -lrt -o pichart-serial pichart.c util.c sieve.c merge.c fourier.c lorenz.c
/SDFS::RISCOSpi.$/Apps/Development/!GCC/bin/ld: cannot find -lrt
collect2: error: ld returned 1 exit status
Makefile:24: recipe for target 'pichart-serial' failed
make: *** [pichart-serial] Error 1
*

RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Why Avoid BASIC on RPi?

Tue Nov 27, 2018 12:50 am

ejolson wrote:
Mon Nov 26, 2018 10:49 pm
DavidS wrote:
Mon Nov 26, 2018 10:21 pm
Heater wrote:
Mon Nov 26, 2018 9:37 pm
That is annoying but...

If it's not defined in any C standard then it hardly the fault of C now is it?
True true. It is the way the programmers use C, and those things that are available to some in C that are outside the standard, not the language.

I am just trying to figure out how to set the value for the define so that it will work to compile and work correctly without any trouble.
Sorry about that. I changed the timing routines to use the newer improved Linux clocks that are guaranteed not to send time backwards after measuring some negative execution times using gettimeofday. For decent sized problems such as the ones in those benchmarks the older timing routines work fine. You can find the older routines in the original Cilk versions of the benchmarks posted here. Or alternatively just paste the following code

Code: Select all

static double tic_time;
void tic() {
    struct timeval tp;
    gettimeofday(&tp,0);
    tic_time=(double) tp.tv_sec + (double) tp.tv_usec * 1.e-6;
}
double toc() {
    struct timeval tp;
    gettimeofday(&tp,0);
    return ((double) tp.tv_sec + (double) tp.tv_usec * 1.e-6)-tic_time;
}
and delete the newer versions of the same functions.
Ok thank you for that. I had gotten distracted in the middle of making my last post so missed your post.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Why Avoid BASIC on RPi?

Tue Nov 27, 2018 12:56 am

jahboater wrote:
Mon Nov 26, 2018 10:50 pm
DavidS wrote:
Mon Nov 26, 2018 10:21 pm
I am just trying to figure out how to set the value for the define so that it will work to compile and work correctly without any trouble.
You cant just do that, as it needs to be supported by your OS.
Even the old gettimeofday() which clock_gettime() replaced did not provide an equivalent for this monotonic timer.
The clock CLOCK_MONOTONIC_RAW is the raw system hardware clock. It will not be affected by micro adjustments from NTP, and it will of course never go backwards due to daylight saving adjustments. The resolution is probably microseconds on the Pi. It starts at some arbitrary time in the past (probably the boot time).
CLOCK_MONOTONIC is the same, but is subject to micro-adjustments. CLOCK_REALTIME is (like gettimeofday()) the clock on the wall time.

I presume this is RISC OS you are using. You need to find a similar clock on RISC OS and replace calls to clock_gettime with calls to your RISC OS swi.

Its probably only used as a hi-res timer to measure speed or something, so it may not be that crucial.

Sorry, cross posted @ejolson's more useful suggestion, but the info here may be of interest - especially if RISC OS doesn't support gettimeofday() either.
So long as NTP is dissabled, as it is the only thing that is going to adjust the time on most RPi RISC OS systems, simply defining CLOCK_MONOTONIC_RAW to the value of CLOCK_MONOTONIC works well in RISC OS, we do still have high resolution HW clocks (even if the more comonly used one is centasecond).

So just have to dissable NTP before running and enable NTP afterwar it is done. For this an Obey file works well (the RISC OS version of a shell script).

See my post two posts back.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

jahboater
Posts: 5173
Joined: Wed Feb 04, 2015 6:38 pm
Location: West Dorset

Re: Why Avoid BASIC on RPi?

Tue Nov 27, 2018 1:58 am

I think you are better off with:
#define CLOCK_MONOTONIC_RAW CLOCK_MONOTONIC
than using gettimeofday() or CLOCK_REALTIME which might jump backwards giving strange negative timings.
and its a small change to the code. Because your glibc is so old, you should add -lrt to the gcc command line.
CLOCK_REALTIME
System-wide clock that measures real (i.e., wall-clock) time. Setting this clock
requires appropriate privileges. This clock is affected by discontinuous jumps in
the system time (e.g., if the system administrator manually changes the clock), and
by the incremental adjustments performed by adjtime(3) and NTP.

CLOCK_REALTIME_COARSE (since Linux 2.6.32; Linux-specific)
A faster but less precise version of CLOCK_REALTIME. Use when you need very fast,
but not fine-grained timestamps.

CLOCK_MONOTONIC
Clock that cannot be set and represents monotonic time since some unspecified
starting point. This clock is not affected by discontinuous jumps in the system
time (e.g., if the system administrator manually changes the clock), but is
affected by the incremental adjustments performed by adjtime(3) and NTP.

CLOCK_MONOTONIC_COARSE (since Linux 2.6.32; Linux-specific)
A faster but less precise version of CLOCK_MONOTONIC. Use when you need very fast,
but not fine-grained timestamps.

CLOCK_MONOTONIC_RAW (since Linux 2.6.28; Linux-specific)
Similar to CLOCK_MONOTONIC, but provides access to a raw hardware-based time that
is not subject to NTP adjustments or the incremental adjustments performed by adj-
time(3).

CLOCK_BOOTTIME (since Linux 2.6.39; Linux-specific)
Identical to CLOCK_MONOTONIC, except it also includes any time that the system is
suspended. This allows applications to get a suspend-aware monotonic clock without
having to deal with the complications of CLOCK_REALTIME, which may have discontinu-
ities if the time is changed using settimeofday(2).

CLOCK_PROCESS_CPUTIME_ID (since Linux 2.6.12)
Per-process CPU-time clock (measures CPU time consumed by all threads in the
process).

CLOCK_THREAD_CPUTIME_ID (since Linux 2.6.12)
Thread-specific CPU-time clock.

jahboater
Posts: 5173
Joined: Wed Feb 04, 2015 6:38 pm
Location: West Dorset

Re: Why Avoid BASIC on RPi?

Tue Nov 27, 2018 2:03 am

On a Pi3B+
This is the output from CLOCK_MONOTONIC

Code: Select all

>> counter
Bin (63) 00000000 00000010 01110111 00011000 | 11110110 10011110 | 01001101 | 01001101 (0)
Oct 23561436647446515,  Dec 693899053911373U,  Hex 27718F69E4D4D
>> counter
Bin (63) 00000000 00000010 01110111 00011001 | 01001101 01011100 | 10010000 | 00011011 (0)
Oct 23561451527110033,  Dec 693900509220891U,  Hex 277194D5C901B
>> counter
Bin (63) 00000000 00000010 01110111 00011001 | 01101000 11111111 | 11010101 | 10100000 (0)
Oct 23561455077752640,  Dec 693900972905888U,  Hex 2771968FFD5A0
>> counter
Bin (63) 00000000 00000010 01110111 00011001 | 10000010 01001110 | 00111000 | 10100110 (0)
Oct 23561460223434246,  Dec 693901397473446U,  Hex 27719824E38A6
>> counter
Bin (63) 00000000 00000010 01110111 00011001 | 10011100 11011101 | 01000100 | 01110000 (0)
Oct 23561463467242160,  Dec 693901843055728U,  Hex 277199CDD4470
>> counter
Bin (63) 00000000 00000010 01110111 00011001 | 10110111 00110000 | 00101001 | 11111111 (0)
Oct 23561466714024777,  Dec 693902284696063U,  Hex 27719B73029FF
>> counter
Bin (63) 00000000 00000010 01110111 00011001 | 11010000 00001101 | 10100101 | 00111110 (0)
Oct 23561472003322476,  Dec 693902701864254U,  Hex 27719D00DA53E
and the is the output from CLOCK_MONOTONIC_RAW

Code: Select all

>> counter
Bin (63) 00000000 00000010 01110111 00100000 | 10110010 00111011 | 01001010 | 00100101 (0)
Oct 23562026216645045,  Dec 693932266310181U,  Hex 27720B23B4A25
>> counter
Bin (63) 00000000 00000010 01110111 00100000 | 11011111 11111110 | 11010101 | 11010101 (0)
Oct 23562033777552725,  Dec 693933034100181U,  Hex 27720DFFED5D5
>> counter
Bin (63) 00000000 00000010 01110111 00100000 | 11111011 10110110 | 00100101 | 11111010 (0)
Oct 23562037355422772,  Dec 693933499098618U,  Hex 27720FBB625FA
>> counter
Bin (63) 00000000 00000010 01110111 00100001 | 00010110 00010100 | 01001010 | 11100010 (0)
Oct 23562042605045342,  Dec 693933941476066U,  Hex 2772116144AE2
>> counter
Bin (63) 00000000 00000010 01110111 00100001 | 00110000 11110000 | 11100101 | 01110010 (0)
Oct 23562046074162562,  Dec 693934392141170U,  Hex 2772130F0E572
>> counter
Bin (63) 00000000 00000010 01110111 00100001 | 01001101 10010111 | 11110110 | 10001011 (0)
Oct 23562051545773213,  Dec 693934872852107U,  Hex 277214D97F68B
>> counter
Bin (63) 00000000 00000010 01110111 00100001 | 01101001 01110111 | 11010010 | 10111100 (0)
Oct 23562055135751274,  Dec 693935340507836U,  Hex 277216977D2BC
>> counter
Bin (63) 00000000 00000010 01110111 00100001 | 10000100 11001101 | 00101000 | 01001000 (0)
Oct 23562060463224110,  Dec 693935799085128U,  Hex 2772184CD2848
>> counter
Bin (63) 00000000 00000010 01110111 00100001 | 10100000 01110001 | 01101000 | 10101010 (0)
Oct 23562064034264252,  Dec 693936262834346U,  Hex 27721A07168AA
>> counter
Bin (63) 00000000 00000010 01110111 00100001 | 10111100 01101010 | 00111110 | 10110010 (0)
Oct 23562067432437262,  Dec 693936732126898U,  Hex 27721BC6A3EB2

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Why Avoid BASIC on RPi?

Tue Nov 27, 2018 2:08 am

jahboater wrote:
Tue Nov 27, 2018 2:03 am
On a Pi3B+
This is the output from CLOCK_MONOTONIC

Code: Select all

>> counter
Bin (63) 00000000 00000010 01110111 00011000 | 11110110 10011110 | 01001101 | 01001101 (0)
Oct 23561436647446515,  Dec 693899053911373U,  Hex 27718F69E4D4D
>> counter
Bin (63) 00000000 00000010 01110111 00011001 | 01001101 01011100 | 10010000 | 00011011 (0)
Oct 23561451527110033,  Dec 693900509220891U,  Hex 277194D5C901B
>> counter
Bin (63) 00000000 00000010 01110111 00011001 | 01101000 11111111 | 11010101 | 10100000 (0)
Oct 23561455077752640,  Dec 693900972905888U,  Hex 2771968FFD5A0
>> counter
Bin (63) 00000000 00000010 01110111 00011001 | 10000010 01001110 | 00111000 | 10100110 (0)
Oct 23561460223434246,  Dec 693901397473446U,  Hex 27719824E38A6
>> counter
Bin (63) 00000000 00000010 01110111 00011001 | 10011100 11011101 | 01000100 | 01110000 (0)
Oct 23561463467242160,  Dec 693901843055728U,  Hex 277199CDD4470
>> counter
Bin (63) 00000000 00000010 01110111 00011001 | 10110111 00110000 | 00101001 | 11111111 (0)
Oct 23561466714024777,  Dec 693902284696063U,  Hex 27719B73029FF
>> counter
Bin (63) 00000000 00000010 01110111 00011001 | 11010000 00001101 | 10100101 | 00111110 (0)
Oct 23561472003322476,  Dec 693902701864254U,  Hex 27719D00DA53E
and the is the output from CLOCK_MONOTONIC_RAW

Code: Select all

>> counter
Bin (63) 00000000 00000010 01110111 00100000 | 10110010 00111011 | 01001010 | 00100101 (0)
Oct 23562026216645045,  Dec 693932266310181U,  Hex 27720B23B4A25
>> counter
Bin (63) 00000000 00000010 01110111 00100000 | 11011111 11111110 | 11010101 | 11010101 (0)
Oct 23562033777552725,  Dec 693933034100181U,  Hex 27720DFFED5D5
>> counter
Bin (63) 00000000 00000010 01110111 00100000 | 11111011 10110110 | 00100101 | 11111010 (0)
Oct 23562037355422772,  Dec 693933499098618U,  Hex 27720FBB625FA
>> counter
Bin (63) 00000000 00000010 01110111 00100001 | 00010110 00010100 | 01001010 | 11100010 (0)
Oct 23562042605045342,  Dec 693933941476066U,  Hex 2772116144AE2
>> counter
Bin (63) 00000000 00000010 01110111 00100001 | 00110000 11110000 | 11100101 | 01110010 (0)
Oct 23562046074162562,  Dec 693934392141170U,  Hex 2772130F0E572
>> counter
Bin (63) 00000000 00000010 01110111 00100001 | 01001101 10010111 | 11110110 | 10001011 (0)
Oct 23562051545773213,  Dec 693934872852107U,  Hex 277214D97F68B
>> counter
Bin (63) 00000000 00000010 01110111 00100001 | 01101001 01110111 | 11010010 | 10111100 (0)
Oct 23562055135751274,  Dec 693935340507836U,  Hex 277216977D2BC
>> counter
Bin (63) 00000000 00000010 01110111 00100001 | 10000100 11001101 | 00101000 | 01001000 (0)
Oct 23562060463224110,  Dec 693935799085128U,  Hex 2772184CD2848
>> counter
Bin (63) 00000000 00000010 01110111 00100001 | 10100000 01110001 | 01101000 | 10101010 (0)
Oct 23562064034264252,  Dec 693936262834346U,  Hex 27721A07168AA
>> counter
Bin (63) 00000000 00000010 01110111 00100001 | 10111100 01101010 | 00111110 | 10110010 (0)
Oct 23562067432437262,  Dec 693936732126898U,  Hex 27721BC6A3EB2
That means I would be better off just jumping over to the code that does not rely on Linux specifics then? The definitions of the two show as the only difference that one can be effected by time corrections (like NTP) while the other can not. Is that without NTP, or other clock modifiers?
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Why Avoid BASIC on RPi?

Tue Nov 27, 2018 2:12 am

jahboater wrote:
Tue Nov 27, 2018 1:58 am
I think you are better off with:
#define CLOCK_MONOTONIC_RAW CLOCK_MONOTONIC
than using gettimeofday() or CLOCK_REALTIME which might jump backwards giving strange negative timings.
and its a small change to the code. Because your glibc is so old, you should add -lrt to the gcc command line.
CLOCK_REALTIME
System-wide clock that measures real (i.e., wall-clock) time. Setting this clock
requires appropriate privileges. This clock is affected by discontinuous jumps in
the system time (e.g., if the system administrator manually changes the clock), and
by the incremental adjustments performed by adjtime(3) and NTP.

CLOCK_REALTIME_COARSE (since Linux 2.6.32; Linux-specific)
A faster but less precise version of CLOCK_REALTIME. Use when you need very fast,
but not fine-grained timestamps.

CLOCK_MONOTONIC
Clock that cannot be set and represents monotonic time since some unspecified
starting point. This clock is not affected by discontinuous jumps in the system
time (e.g., if the system administrator manually changes the clock), but is
affected by the incremental adjustments performed by adjtime(3) and NTP.

CLOCK_MONOTONIC_COARSE (since Linux 2.6.32; Linux-specific)
A faster but less precise version of CLOCK_MONOTONIC. Use when you need very fast,
but not fine-grained timestamps.

CLOCK_MONOTONIC_RAW (since Linux 2.6.28; Linux-specific)
Similar to CLOCK_MONOTONIC, but provides access to a raw hardware-based time that
is not subject to NTP adjustments or the incremental adjustments performed by adj-
time(3).

CLOCK_BOOTTIME (since Linux 2.6.39; Linux-specific)
Identical to CLOCK_MONOTONIC, except it also includes any time that the system is
suspended. This allows applications to get a suspend-aware monotonic clock without
having to deal with the complications of CLOCK_REALTIME, which may have discontinu-
ities if the time is changed using settimeofday(2).

CLOCK_PROCESS_CPUTIME_ID (since Linux 2.6.12)
Per-process CPU-time clock (measures CPU time consumed by all threads in the
process).

CLOCK_THREAD_CPUTIME_ID (since Linux 2.6.12)
Thread-specific CPU-time clock.
Uhm I do not have glibc I have two choices for a C library on RISC OS, either CLib which is the default built into the OS, or UnixLib which is meant to ease porting of programs from Unix like systems (like Linux), and has a lot of overhead (though does not have the this), and it is not old by any means, the current version I think is less than a month old. It is not glibc and that is the issue.

Also I do have -lrt on the command line, wondering what needs it?
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Why Avoid BASIC on RPi?

Tue Nov 27, 2018 2:17 am

Ok I just tried to compile omitting -lrt from CFLAGS, and the result was:

Code: Select all

*make
gcc -std=gnu99 -O3 -ffast-math -Wall -lm -o pichart-serial pichart.c util.c sieve.c merge.c fourier.c lorenz.c
*

so what needs rt?

I admit I have yet to try to run it, though that is looking prety good so far.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Why Avoid BASIC on RPi?

Tue Nov 27, 2018 2:20 am

It is running in RISC OS, no errors yet. Just started, I will post the output when it finnishes.

Fingers crossed, as I type this while it is running on the same system :) .
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

ejolson
Posts: 4452
Joined: Tue Mar 18, 2014 11:47 am

Re: Why Avoid BASIC on RPi?

Tue Nov 27, 2018 2:23 am

DavidS wrote:
Tue Nov 27, 2018 12:48 am
Ok I figured out what the value of CLOCK_MONOTONIC_RAW is supposed to be, and in most cases it will work to define it as CLOCK_MONOTONIC, so that fixes the issue, and I am as close to a compile as I could expect beings the differences in the environments:

Code: Select all

*make
gcc -std=gnu99 -O3 -ffast-math -Wall -lm -lrt -o pichart-serial pichart.c util.c sieve.c merge.c fourier.c lorenz.c
/SDFS::RISCOSpi.$/Apps/Development/!GCC/bin/ld: cannot find -lrt
collect2: error: ld returned 1 exit status
Makefile:24: recipe for target 'pichart-serial' failed
make: *** [pichart-serial] Error 1
*

It appears all the trouble is related to those improved timing routines. On some versions of Linux the clock_gettime function is in librt so I included it. If you are using gettimeofday the -lrt flag is not needed. It is also not needed on many newer versions of Linux. Try leaving it out. If the program links then everything should be fine.

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Why Avoid BASIC on RPi?

Tue Nov 27, 2018 3:01 am

ejolson wrote:
Tue Nov 27, 2018 2:23 am
DavidS wrote:
Tue Nov 27, 2018 12:48 am
Ok I figured out what the value of CLOCK_MONOTONIC_RAW is supposed to be, and in most cases it will work to define it as CLOCK_MONOTONIC, so that fixes the issue, and I am as close to a compile as I could expect beings the differences in the environments:

Code: Select all

*make
gcc -std=gnu99 -O3 -ffast-math -Wall -lm -lrt -o pichart-serial pichart.c util.c sieve.c merge.c fourier.c lorenz.c
/SDFS::RISCOSpi.$/Apps/Development/!GCC/bin/ld: cannot find -lrt
collect2: error: ld returned 1 exit status
Makefile:24: recipe for target 'pichart-serial' failed
make: *** [pichart-serial] Error 1
*

It appears all the trouble is related to those improved timing routines. On some versions of Linux the clock_gettime function is in librt so I included it. If you are using gettimeofday the -lrt flag is not needed. It is also not needed on many newer versions of Linux. Try leaving it out. If the program links then everything should be fine.
I am still using clock_gettime(), on RISC OS, and there is no such thing as librt on RISC OS, so it is in UnixLib (one of our two C libraries, that I used to get it done).

Once I left out the -lrt switch it built without issue, and is running now. See above post.

It is running now, though I did not see anywhere where you reported the total run time on the low end systems, so I have no idea how long to wait for it. Though I asked about the time issue in the main thread about Pi-Piechart.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

ejolson
Posts: 4452
Joined: Tue Mar 18, 2014 11:47 am

Re: Why Avoid BASIC on RPi?

Tue Nov 27, 2018 3:08 am

DavidS wrote:
Tue Nov 27, 2018 3:01 am
ejolson wrote:
Tue Nov 27, 2018 2:23 am
DavidS wrote:
Tue Nov 27, 2018 12:48 am
Ok I figured out what the value of CLOCK_MONOTONIC_RAW is supposed to be, and in most cases it will work to define it as CLOCK_MONOTONIC, so that fixes the issue, and I am as close to a compile as I could expect beings the differences in the environments:

Code: Select all

*make
gcc -std=gnu99 -O3 -ffast-math -Wall -lm -lrt -o pichart-serial pichart.c util.c sieve.c merge.c fourier.c lorenz.c
/SDFS::RISCOSpi.$/Apps/Development/!GCC/bin/ld: cannot find -lrt
collect2: error: ld returned 1 exit status
Makefile:24: recipe for target 'pichart-serial' failed
make: *** [pichart-serial] Error 1
*

It appears all the trouble is related to those improved timing routines. On some versions of Linux the clock_gettime function is in librt so I included it. If you are using gettimeofday the -lrt flag is not needed. It is also not needed on many newer versions of Linux. Try leaving it out. If the program links then everything should be fine.
I am still using clock_gettime(), on RISC OS, and there is no such thing as librt on RISC OS, so it is in UnixLib (one of our two C libraries, that I used to get it done).

Once I left out the -lrt switch it built without issue, and is running now. See above post.

It is running now, though I did not see anywhere where you reported the total run time on the low end systems, so I have no idea how long to wait for it. Though I asked about the time issue in the main thread about Pi-Piechart.
Hm. The serial version shouldn't take more than 5 to 10 minutes, usually much faster. As stated before, if the timing routines are broken, the benchmark will get stuck in an infinite loop waiting for 5 seconds to pass. The program will print a line out between each of the four tests. If you are still on the first test, likely the clock_gettime function is broken. In that case, comment out the included tic and toc routines and try the alternative tic and toc routines that I posted above based on gettimeofday.

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Why Avoid BASIC on RPi?

Tue Nov 27, 2018 3:32 am

It is running with the alternate tic() and toc() functions for 8 minutes now without completign a single test yet.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Why Avoid BASIC on RPi?

Tue Nov 27, 2018 3:55 am

I am thinking that something else is off. Looking at sieve.c I found that you are looking for the running total if succesive calls to tic and toc to add up to 5, I do not hhink that is a very good way around it.

I think a better way would be to have the call to tic start the time, and have toc return only the time difference in an integer of seconds. That is use clock() as the time keeping function (which is part of the C standard lib), store the value of clock in tic, then return from toc with the value (int)clock() / CLOCKS_PER_SEC - tic_time then in the caller just see if the return from toc is equal to or greater than 5. This would get around any calculation error, and potential FP rounding error.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

ejolson
Posts: 4452
Joined: Tue Mar 18, 2014 11:47 am

Re: Why Avoid BASIC on RPi?

Tue Nov 27, 2018 4:05 am

DavidS wrote:
Tue Nov 27, 2018 3:32 am
It is running with the alternate tic() and toc() functions for 8 minutes now without completign a single test yet.
That is strange. I think the prime sieve test should complete in 2 to 3 minutes--eight independent timings of about 20 seconds each on a Pi B+ running at the default 700 MHz. What version of gcc are you compiling with?

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Why Avoid BASIC on RPi?

Tue Nov 27, 2018 4:10 am

Ok I have eliminated the tic() and toc() routines as the cause, and I am headed for bed.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Why Avoid BASIC on RPi?

Tue Nov 27, 2018 4:12 am

ejolson wrote:
Tue Nov 27, 2018 4:05 am
DavidS wrote:
Tue Nov 27, 2018 3:32 am
It is running with the alternate tic() and toc() functions for 8 minutes now without completign a single test yet.
That is strange. I think the prime sieve test should complete in 2 to 3 minutes--eight independent timings of about 20 seconds each on a Pi B+ running at the default 700 MHz. What version of gcc are you compiling with?
gcc 4.7.4, the newest currently available on RISC OS.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

Return to “Off topic discussion”