采用64位处理器的树莓派3B，虽然具有64位硬件，但是系统还没有跟上节奏。官方尚未正式发布64位Raspbian，近期有团队移植了Debian 9 arm64到树莓派3B，将“装死”一年多的树莓派3B的性能完全释放出来，测试跑下来发现CPU性能最高比32位系统高30倍！
本文将介绍如何进行对比跑分测试。
硬件测试环境：
- RaspberryPi 3 Model B
- 16GB Class 10 TF卡
- 5v2.5A电源
- 以太网网线及能连外网路由设备
软件测试环境：
- GEEEKPI-64bit-beta（内核移植版，操作系统是基于Debian 9的arm64位源码，Debian 9目前还没发布，目前属于beta版，RaspberryPi 官方也没有发布64bit操作系统的计划，但是我们迫切需要64bit的性能）
- sysbench 压力测试软件
首先开机后联网，两台设备全部进入字符界面（console）模式，外部不连接任何外设，通过ssh远程登录到两台主机上，然后安装sysbench软件进行压力测试，并通过htop简单的进行观察。
执行命令为:
sudo apt-get update && sudo apt-get –y install sysbench htop iperf3
性能测试命令如下：
#测试CPU性能： sysbench —test=cpu —num-threads=1 —max-requests=10000 run #4线程测试： sysbench —test=cpu —num-threads=4 —max-requests=100000 run #8线程测试： sysbench —test=cpu —num-threads=8 —max-requests=100000 run #测试内存性能 #内存随机测试： sysbench —test=memory --memory-block-size=1K –memory-total-size=1G --memory-access-mode=rnd run #内存连续测试： sysbench —test=memory --memory-block-size=1K –memory-total-size=1G --memory-access-mode=seq run #测试网络性能： iperf3 -c 192.168.1.2 #八线程测试共享线程锁： sysbench --test=threads --num-threads=1000 --thread-yields=1000 --thread-locks=8 run #互斥锁测试 sysbench --test=mutex --mutex-num=4096 --mutex-locks=50000 --mutex-loops=10000 run #连续读写： sysbench --test=fileio --file-num=2 --file-total-size=64M --file-test-mode=seqrewr run #随机文件读写： sysbench --test=fileio --file-num=2 --file-total-size=64M --file-test-mode=rndwr run #进入系统检查系统版本信息及硬件架构平台信息 df -Th
完整测试截图可以在这里下载（感谢yoyojacky提供）。
总结：
GEEEKPI 团队最终对比表格如下：
| 测试项目 | Raspbian2017-03-03 | Debian 9 Arm64bit | 提升倍数 |
| 系统信息 | Arm 32bit/ext4文件系统 | Aarm64bit/f2fs文件系统 | 见文件系统测试 |
| CPU单线程 | 367.2971 | 25.1195 | 14.62倍 |
| 四线程 | 1017.6742 | 62.6079 | 16.40倍 |
| 八线程 | 1920.0601 | 62.6711 | 30.64倍 |
| 内存随机 | 5.7678 | 2.1925 | 2.63倍 |
| 内存连续 | 6.3309 | 2.9392 | 2.15倍 |
| 网络性能 | 74.6Mbps | 94.3Mbps | 1.26倍 |
| 文件连续读写 | 5.7655 | 7．1506 | 见下文说明 |
| 文件随机读写 | 不支持 | 21.8336 | 无 |
| 互斥锁性能 | 0.0231s | 0.0186s | 1.24倍 |
Debain 9 文件系统采用了三星与华为合力开发的f2fs，针对mmc和emmc还有tf存储进行了优化，除了大大提升了性能之外，还增加了TF卡的使用寿命，提供了意外断电文件系统的保护，大大避免意外断电导致的文件系统崩溃的情况。
其中由于TF卡的细微差异，导致文件连续读写出现了反转，实际上通过测试文件连续读写的性能方面，f2fs更加优化，超越ext4很多倍。
总体上，64位的系统提供了更好的使用体验，曾经抱怨树莓派跑opencv性能不佳的朋友应该是看到希望了！
以上测试并非使用官方系统，但能够让大家看到软硬件匹配64位之后，树莓派性能上的提升潜力。作为树莓派爱好者，一起期待官方发布64位系统吧！
测试数据摘自：《树莓派64位系统来袭，速度最快提升30倍！》
这是一篇发布于 8年 前的文章，其中的信息可能已经有所发展或是发生改变，请了解。
已添加完整测试截图
https://pan.baidu.com/s/1dECyihr
感谢yoyojacky提供
真是好消息，期待早日3b官方系统能升级到64bit
。。。总觉得这个评测哪里有问题，64bit本质上不会带来多少性能提升的
事实上，就算64bit的系统，大部分应用也是32bit的，所以除非做一些并行计算方面的研究或安装64位的应用，否则性能应该不会有太大改变，变化大基本上是因为系统升级优化导致的
这个系统的下载放出了吗？google都找不到
关键是温度下来了，我只是简单的通过数据比对算出的结论，而且编译的时候速度明显加快，多核之间的切换也是很平滑。可能测试的方法比较low吧。欢迎大家批评指正啦！
你好，我烧写完64bit的系统后，系统无法启动。不知道你遇到过这个问题么。
** Unable to read “uboot.env” from mmc0:1 **
Using default environment
In: serial
Out: lcd
Err: lcd
Net: Net Initialization Skipped
No ethernet found.
starting USB…
USB0: Core Release: 2.80a
scanning bus 0 for devices… 3 USB Device(s) found
scanning usb for storage devices… 0 Storage Device(s) found
scanning usb for ethernet devices… 1 Ethernet Device(s) found
Hit any key to stop autoboot: 0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1…
Found EFI removable media binary efi/boot/bootaa64.efi
reading efi/boot/bootaa64.efi
606208 bytes read in 73 ms (7.9 MiB/s)
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
## Starting EFI application at 0x01000000 …
Scanning disks on usb…
Scanning disks on mmc…
MMC Device 1 not found
MMC Device 2 not found
MMC Device 3 not found
Found 5 disks
Welcome to GRUB!
error: terminal `gfxterm’ isn’t found.
EFI stub: Booting Linux Kernel…
EFI stub: UEFI Secure Boot is enabled.
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services and installing virtual address map…