Our team founder KF7IJZ is up to 1.3M and we're getting close to that special Pi number. Has anyone contacted the Rpi foundation to see if they want to run a story about the team?
Thankyou N30DG. Not sure if I can squeeze the out-of-place FFT into memory. Running the cache down on one to give it a try. All are running headless.
I wonder what the project position with this is. Usually any optimisations are put back into the standard app so I wouldn't be surprised if the in-place FFT version becomes the standard.
Thankyou N30DG. Not sure if I can squeeze the out-of-place FFT into memory. Running the cache down on one to give it a try. All are running headless.
No problem, glad to help :).
I'm running the out-of-place without any trouble on a standart Raspbian Jessie Lite installation. It fit's into the RAM without using Swap. For a "crunching-only-device" this is the best choice.
PorkyPies wrote:
I wonder what the project position with this is. Usually any optimisations are put back into the standard app so I wouldn't be surprised if the in-place FFT version becomes the standard.
I think there is a little Problem with this: BOINC detects a false CPU on the RPI-3. It shows ARM ARMv7 Processor rev 4 but that is wrong. It should be ARMv8. The Performance-increase is mainly from compiling the App for the new Architecture.
My code changes are only little adjustments to make the App more "ARM-friendly". I never benched how much they improve performance on the PI. But from my expierence with the Odroid-C2, i would guess they are around 3000sec. Independent from out-of-place or in-place. This changes maybe applicable for ARMv7 too.
But the rest is just a recompile for the new ARMv8-Architcture. As far as Boinc reports a false CPU its maybe not possible to send the right App-Version out. But I'm not shure with that. I don't know what's going on on the server-side. Maybe there are much more detailed Informations about the CPU. Only someone from the Einstein-Team can answer that ;).
regardless of that: If someone needs somethink from this little Project (build-script, wisdom, changed sourcecode-files[are the same as for the Odroid-C2], etc...) send me a PM :)
I think there is a little Problem with this: BOINC detects a false CPU on the RPI-3. It shows ARM ARMv7 Processor rev 4 but that is wrong. It should be ARMv8. The Performance-increase is mainly from compiling the App for the new Architecture.
My code changes are only little adjustments to make the App more "ARM-friendly". I never benched how much they improve performance on the PI. But from my expierence with the Odroid-C2, i would guess they are around 3000sec. Independent from out-of-place or in-place. This changes maybe applicable for ARMv7 too.
BOINC is just getting it from /proc/cpuinfo. This is what mine says (running stretch). It might be a bug with Raspbian mis-reporting it as an ARM v7 when in fact it should be an ARM v8, in which case we might need to log a Rpi bug.
processor : 0 model name : ARMv7 Processor rev 4 (v7l) BogoMIPS : 38.40 Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xd03 CPU revision : 4
processor : 1 model name : ARMv7 Processor rev 4 (v7l) BogoMIPS : 38.40 Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xd03 CPU revision : 4
processor : 2 model name : ARMv7 Processor rev 4 (v7l) BogoMIPS : 38.40 Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xd03 CPU revision : 4
processor : 3 model name : ARMv7 Processor rev 4 (v7l) BogoMIPS : 38.40 Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xd03 CPU revision : 4
Hardware : BCM2709 Revision : a22082
[edit]
Looks like other people have reported it. The suggestions are that in 32 bit mode it reports itself as a ARM v7 and if it were running a 64 bit OS would show itself as an ARMv8.
Looks like other people have reported it. The suggestions are that in 32 bit mode it reports itself as a ARM v7 and if it were running a 64 bit OS would show itself as an ARMv8.
But how to differentiate between a ARMv8 in 32bit-mode and a real ARMv7? Are there a 64bit OS for the RPI3 out?
But how to differentiate between a ARMv8 in 32bit-mode and a real ARMv7? Are there a 64bit OS for the RPI3 out?
The Raspberry Pi foundation are "looking into" using a 64 bit OS. I suspect that might have to wait for a Pi4 as they'd want more than 1Gb of memory for a 64 bit OS. Debian has an ARM64 architecture so I wouldn't think it would be too hard to get to a 64 bit OS and then there's Ubuntu and others.
From what I read yesterday the current tool chain doesn't support the additional instructions that the ARMv8 has apart from CRC32. I am not sure why, maybe something the foundation have done in their customisations to get Debian to run on the Pi.
From what I read yesterday the current tool chain doesn't support the additional instructions that the ARMv8 has apart from CRC32. I am not sure why, maybe something the foundation have done in their customisations to get Debian to run on the Pi.
The 32bit-mode on ARMv8 is designed to be a "ARMv7-compatiblity-mode". Thats why there tool-chain don't uses the new Instructions. And maybe that's why the report the CPU as ARMv7.
As you can see the AARCH64-state is much more powerfull than the AARCH32-state used on the RPI3.
Debian have arm64-resources. On my Odroid-C2 I'm running Debian. So that can't be the reason why the decided to stick at 32bit. But at the moment we have to deal with it. All we can do about that is wait
Here's the FreeDC link to the
)
Here's the FreeDC link to the team: http://stats.free-dc.org/stats.php?page=team&proj=eah&team=14502
Our team founder KF7IJZ is up to 1.3M and we're getting close to that special Pi number. Has anyone contacted the Rpi foundation to see if they want to run a story about the team?
MarksRpiCluster
I've finished the optimized
)
I've finished the optimized BRP-App for RPI 3
.
https://einsteinathome.org/de/content/high-speed-linux-brp-app-raspberry-pi-3
It should double the RAC of the PI 3 using the out-of-place Version.
Happy crunching
Thankyou N30DG. Not sure if I
)
Thankyou N30DG. Not sure if I can squeeze the out-of-place FFT into memory. Running the cache down on one to give it a try. All are running headless.
I wonder what the project position with this is. Usually any optimisations are put back into the standard app so I wouldn't be surprised if the in-place FFT version becomes the standard.
MarksRpiCluster
PorkyPies wrote:Thankyou
)
No problem, glad to help :).
I'm running the out-of-place without any trouble on a standart Raspbian Jessie Lite installation. It fit's into the RAM without using Swap. For a "crunching-only-device" this is the best choice.
I think there is a little Problem with this: BOINC detects a false CPU on the RPI-3. It shows ARM ARMv7 Processor rev 4 but that is wrong. It should be ARMv8. The Performance-increase is mainly from compiling the App for the new Architecture.
My code changes are only little adjustments to make the App more "ARM-friendly". I never benched how much they improve performance on the PI. But from my expierence with the Odroid-C2, i would guess they are around 3000sec. Independent from out-of-place or in-place. This changes maybe applicable for ARMv7 too.
But the rest is just a recompile for the new ARMv8-Architcture. As far as Boinc reports a false CPU its maybe not possible to send the right App-Version out. But I'm not shure with that. I don't know what's going on on the server-side. Maybe there are much more detailed Informations about the CPU. Only someone from the Einstein-Team can answer that ;).
regardless of that: If someone needs somethink from this little Project (build-script, wisdom, changed sourcecode-files[are the same as for the Odroid-C2], etc...) send me a PM :)
Quote:I think there is a
)
BOINC is just getting it from /proc/cpuinfo. This is what mine says (running stretch). It might be a bug with Raspbian mis-reporting it as an ARM v7 when in fact it should be an ARM v8, in which case we might need to log a Rpi bug.
processor : 0
model name : ARMv7 Processor rev 4 (v7l)
BogoMIPS : 38.40
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xd03
CPU revision : 4
processor : 1
model name : ARMv7 Processor rev 4 (v7l)
BogoMIPS : 38.40
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xd03
CPU revision : 4
processor : 2
model name : ARMv7 Processor rev 4 (v7l)
BogoMIPS : 38.40
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xd03
CPU revision : 4
processor : 3
model name : ARMv7 Processor rev 4 (v7l)
BogoMIPS : 38.40
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xd03
CPU revision : 4
Hardware : BCM2709
Revision : a22082
[edit]
Looks like other people have reported it. The suggestions are that in 32 bit mode it reports itself as a ARM v7 and if it were running a 64 bit OS would show itself as an ARMv8.
MarksRpiCluster
PorkyPies wrote:Looks like
)
But how to differentiate between a ARMv8 in 32bit-mode and a real ARMv7? Are there a 64bit OS for the RPI3 out?
N30dG wrote:But how to
)
The Raspberry Pi foundation are "looking into" using a 64 bit OS. I suspect that might have to wait for a Pi4 as they'd want more than 1Gb of memory for a 64 bit OS. Debian has an ARM64 architecture so I wouldn't think it would be too hard to get to a 64 bit OS and then there's Ubuntu and others.
From what I read yesterday the current tool chain doesn't support the additional instructions that the ARMv8 has apart from CRC32. I am not sure why, maybe something the foundation have done in their customisations to get Debian to run on the Pi.
MarksRpiCluster
PorkyPies wrote:From what I
)
The 32bit-mode on ARMv8 is designed to be a "ARMv7-compatiblity-mode". Thats why there tool-chain don't uses the new Instructions. And maybe that's why the report the CPU as ARMv7.
Here are some Benchmark results about that: link
As you can see the AARCH64-state is much more powerfull than the AARCH32-state used on the RPI3.
Debian have arm64-resources. On my Odroid-C2 I'm running Debian. So that can't be the reason why the decided to stick at 32bit. But at the moment we have to deal with it. All we can do about that is wait
Thank you N30DG! I will try
)
Thank you N30DG! I will try to get this installed on at least one node of my Pi 3 Cluster this week or weekend to give it a whirl!
My YouTube Channel: https://www.youtube.com/user/KF7IJZ
Follow me on Twitter: https://twitter.com/KF7IJZ
Raspberry Pi team passed 3.14
)
Raspberry Pi team passed 3.14 million
MarksRpiCluster