Bootable 64-bit RPi3 Gentoo image (OpenRC/Xfce/VC4) UPDATED

[Sakaki]

R0b0t1,
following on from what NeddySeagoon just said, what do you get on your SD-card image if you run lsmod? Check the vc4 module is loaded, here's the output from my gentoo-on-rpi3-64bit image, for example:

[R0b0t1]

Thanks NeddySeagoon,

When I switched kernels I left Sakaki's config.txt intact. I checked to make sure that the dtoverlay line for the VC4 firmware was there before posting. Please see the other thread I started if you still feel like helping, I don't want to clutter this one.

Sakaki, I will attempt later and edit this post. Thanks.

[roylongbottom]

Latest programs converted were my Fast Fourier Transform benchmarks that showed some 64 bit performance improvements. Details, results, source code and execution files can be obtained clicking on the links given earlier or via the www button below.

These execute FFTs sized 1K to 1024K, the larger ones depending on RAM speeds. Using Raspbian (32 bit) and Linux/RPi (64 bit), the short FFTs, with execution times of less than 0.5 milliseconds, produced inconsistent running times. This was only with "on demand" MHz settings and not when running another CPU benchmark at the same time, using a different core, or with a “performance” MHz setting. I haven’t found how to set “performance with Gentoo. Is it possible?

To investigate this, I produced another test that executes 30 1K sized FFTs 500 times, with 32 bit and 64 bit compilations (These are included in the tar.gz file). Example results are below.

[NeddySeagoon]

roylongbottom,

All things are possible in Gentoo, its just missing the GUI, so you need to poke about a bit from the console.

[khayyam]

[NeddySeagoon]

Heh, just like everything else in Gentoo, there are lots of ways to do everything and they are all equally right.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[mDup]

Does anyone have a prebuilt Firefox v51.0.1 arm64 gentoo package tarball?
I run gentoo on amlogic s905 and cannot build firefox, but then that's my own fault because I use gcc 6.3.0 for entire portage.
Nevertheless I can run prebuilt rpi3-64 Firefox v50.1.0 package, and so now I wonder if I can get an upgrade.

[NeddySeagoon]

mDup,

It won't build here. It looks like the build system is broken.

[roylongbottom]

[khayyam]

[mDup]

[NeddySeagoon]

mDup,

I've only tried the firefox in the tree. From your code fragment,

[roylongbottom]

I am converting my MP benchmarks to run at 64 bits. Initially they are being successfully compiled and run via OpenSUSE using gcc-6. The multithreaded programs also run via Gentoo but not the OpenMP tests, where libgomp.so.1 is not found and the benchmarks can't be compiled using Gentoo gcc 5.4. Is OpenMP or the library available and, if so, how do I install them?

Future requirement is OpenGL, particularly equivalent of Raspberry Pi freeglut3. Is that available? I installed OpenGL 7.0 (I think) but can't find it.
_________________
Regards

Roy

[NeddySeagoon]

roylongbottom,

equery can tell you lots of things about installed packages.

[mDup]

[Sakaki]

@mDup, @NeddySeagoon

[mDup]

[khayyam]

[roylongbottom]

Most of my multithreading benchmarks run using 1, 2, 4 and 8 threads. Many have tests that use approximately 12 KB. 120 KB and 12 MB, to use both caches and RAM. The first set attempt to measure maximum MFLOPS. with two test procedures, one with two floating point operations per data word and the other with 32. The latter includes a mixture of multiplications and additions, coded to enable SIMD operation. In this case, using single precision numbers, four at a time, plus linked multiply and add, a top end CPU can execute eight operations per clock cycle per core. It is not clear what the potential maximum MFLOPS is on an ARM Cortex-A53, but eight per core is mentioned. The same benchmark code obtained a maximum of 24 MFLOPS/MHz on a top end quad core Intel CPU, via Linux - see the following:

http://www.roylongbottom.org.uk/linux%20multithreading%20benchmarks.htm#anchor6

Then this ARM CPU might need a different combination of arithmetic operations for higher values, where best case obtained with this benchmark was 2.2 MFLOPS/MHz using a single core.

Following shows the format of the MP-MFLOPS benchmarks with the best 64 bit Raspberry Pi 3 results. Note performance increases using more threads, except when limited by RAM speed. These benchmarks carry out a fixed number of test passes, with each thread carrying out the same calculations on different sections of data. Numeric results produced (x 100000) are output to show that all data has been used.

[roylongbottom]

The other MP benchmarks, included in the tar.gz file, demonstrate some MP and 64 bit performance gains, with others identifying that multithreading provided little or no benefit and, sometimes, much worse performance.

MP-Whetstone - Multiple threads each run the eight test functions at the same time, but with some dedicated variables. MP performance is good but the simple test functions are nit appropriate for more advanced instructions at 64 bits, so relative 32 bit performance is between 0.48 and 2.08.

MP-Dhrystone - This runs multiple copies of the whole program at the same time. Dedicated data arrays are used for each thread but there are numerous other variables that are shared. The latter reduces performance gains via multiple threads and, in some cases, these can be slower than using a single thread. In this case, some quad core improvements are shown as up to 2.5 times faster than a single core. Single core 64 bit/32 bit speed ratio was 1.50 reducing to 1.10 using four threads.

MP-Linpack - The original Linpack Benchmark operates on double precision floating point 100x100 matrices. This one runs on 100x100, 500x500 and 1000x1000 single precision matrices using 0, 1, 2 and 4 separate threads, mainly via NEON intrinsic functions that are compiled into different forms of vector instructions. The benchmark was produced to demonstrate that the original Linpack code could not be converted (by me) to show increased performance using multiple threads. The official line is that users are allowed to implement their own linear equation solver for this purpose. At 100 x 100, data is in L2 cache, others depend more on RAM speed. The critical daxpy function is affected by numerous thread create and join directives, even on using one thread. This leads to slow and constant performance using all thread tests - see example below. The 32 bit version produced slightly slower speeds.

[Zucca]

Has anyone tried to convert the existing ext4 filesystem to btrfs?
I think the snapshotting feature of it could be useful there.
_________________
..: Zucca :..

[roylongbottom]

OpenGL GLUT Benchmark

This was produced for use on Linux based PCs. It has four tests using coloured or textured simple objects then a wireframe and textured complex kitchen structure. It can be run from a script file specifying different window sizes and a command to disable VSYNC, enabling speeds greater than 60 FPS to be demonstrated. The benchmark, source code and details are in the following:

http://www.roylongbottom.org.uk/Rpi3-64-Bit-Benchmarks.tar.gz
http://www.roylongbottom.org.uk/Raspberry%20Pi%20Benchmarks.htm#anchor19a

In 2012, I approved a request from a Quality Engineer at Canonical, to use this OpenGL benchmark in the testing framework of the Unity desktop software. One reason probably was that a test can be run for extended periods as a stress test.

Below are results from a Raspberry Pi 3, using the experimental desktop GL driver and the new 64 bit version. It can be seen that, using smaller windows, the 32 bit version was much faster running simple coloured objects, with the 64 bit benchmark being ahead with complex structures. Then, performance was quite similar with full screen displays.

[NeddySeagoon]

roylongbottom,

I haven't tried 32 bit Java for the Pi but you can build both Java 1.7 and once you have 1.7 you can use it to build 1.8.
If I got the keywording right, keywording is no longer required.

Its also possible to build Icedtea with Oracles Java. That's documented there too.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[roylongbottom]

My DriveSpeed and LanSpeed programs have now been recompiled as DriveSpeed64 and LanSpeed64, with benchmarks, source codes, details and results in the tar.gz and htm files quoted earlier. The code for these is identical, except DriveSpeed opens files to use direct I/O, avoiding caching. LanSpeed normally runs without using local caching. The benchmarks measure writing and reading speeds of relatively large files, random access and numerous small files.

There might be tuning parameter, but DriveSpeed64 produced errors using the installed Gentoo operating system, where direct I/O did not appear to be available. The benchmarks was validated on a different 64 bit system.

DriveSpeed can also be used for testing USB connected drives. This produced errors using flash drives but happened to run testing a micro SD card, via a USB card reader, but only one via a btrfs formatted partition. Results are below but, compared with earlier 32 bit tests, some speeds are not as expected.

[roylongbottom]

Stress Testing Programs

The Cortex-A53 CPU, used in the Raspberry Pi 3, is known to be subject to overheating. Assuming correct software implementation, the first noticeable effect is that, as the temperature increases beyond a critical point, the CPU MHz is throttled. At normal room temperatures, this might only occur when all CPU cores are executing at higher speeds, with a possible contribution from graphics activity. When considered important, special cooling arrangements might be needed, where these stress tests will be of use to evaluate different arrangements. For this series of procedures, the RPI 3 board was “out of case”, where recorded temperatures are often shown to be lower than those obtained using a standard plastic enclosure.

A main consideration for stress testing is that programs have parameters to run for defined durations but with short term reports on progress, including performance and, in this case, CPU temperature and clock MHz. These details should also be saved in constantly updated log files. Then, there will be some evidence, if the system crashes.

In this case, multiple programs are run using a different terminal window for each, normally with 15 minutes test duration specified. One of these measures CPU temperature MHz at specified intervals, where vcgencmd function has to be installed (as used by Raspbian). Two of the programs are benchmarks, already reported on, but with alternative run time parameters, and two are new ones, now with programs, source code and detailed results included in:

http://www.roylongbottom.org.uk/Rpi3-64-Bit-Benchmarks.tar.gz
http://www.roylongbottom.org.uk/Raspberry%20Pi%20Benchmarks.htm

The oldest uses linverloopsPi64, Livermore Loops Benchmark, that has 24 different test kernels, repeated three time with different (cache) memory demands. This was known to produce wrong numeric answers on an overclocked PC. For reliability testing, a parameter specifies a standard time for each of the loops. Results are displayed during the tests, but performance reported and logged is at the end. The main benefit is a continuously changing processing profile.

The other existing benchmark is videogl64 via OpenGL. This has six tests procedures, where one is chosen besides the number of passes and duration of each. The window width and height can be specified, allowing visible screen space where other terminal windows can be displayed.

The new tests have a run time parameter to specify the amount of cache or memory space to use, and carry out high speed integer and floating point calculations via stressintPi64 and burninfpuPi64.

A summary of test results is;

Integer Arithmetic Stress Test - comprising four runs of stressintPi64 using 40 KB of data, aimed at all using L2 cache, with 12 tests each running for 80 seconds. Performance on all cores was essentially the same, with CPU throttling starting after 30 seconds, eventually reducing CPU MHz by nearly 32%, with maximum recorded sample CPU temperature of 84.4 °C. Compared with stand alone results, CPU performance was degraded to a greater extent due to MP overheads.

Floating Point Arithmetic Stress Test - having four burninfpuPi64 test procedures, using L2 cache with 8 operations per data word. Again performance was effectively constant from all cores, with maximum total throughput of 13.7 GFLOPS, reducing by nearly 4 GFLOPS due to CPU throttling down to 843 MHz, again with a maximum temperature of 84.4 °C.

Livermore Loops Stress Test - This uses four copies of the Livermore Loops Benchmark. Overall MFLOPS speeds are shown to be significantly degraded, but RPiHeatMHz64 results demonstrate inconsistent effects of different arithmetic functions. Maximum temperature recorded was 84.9 °C with a CPU MHz of 744.

Integer and OpenGL Stress Tests - The most complicated OpenGL kitchen test was used, along with three Integer Stress Tests., this time using L1 cache based data. The same procedures were used with CPU MHz settings of On-demand and Performance, where results are shown to be virtually the same. The first summary of speeds and temperatures below is with the Performance setting. Then, OpenGL FPS and integer MB/second reduced to around 60% of initial speeds, with many temperatures of 84.9 °C recorded, when CPU MHz temporarily dropped to half speed at 600 MHz. The tests were repeated with the system in a FLIRC case, where the whole aluminium case becomes the heatsink. The performance was consistently high, but temperatures approached the critical CPU throttling would occur.