User avatar
ambrosa
Posts: 7
Joined: Tue Feb 03, 2015 6:08 am
Location: Milan - Italy
Contact: Website

RPI 2 : Raspbian or Debian "armhf" ?

Tue Feb 03, 2015 6:21 am

Yesterday I've bought my first RPI 2.
Before I've used for a long time a Cubieboard based on a Allwinner A10 cpu ARMv7, the same ARMv7 arch used in new RPI 2 board (GPU closed source: no XBMC sigh).

In my Cubieboard I simply use standard Debian Wheezy "armhf". Only the kernel is build with patch for specific Cubieboard hardware.
I suppose that standard Debian Wheezy "armhf" can run fine into RPI2 ARMv7 (or not ??).

Because Raspbian is compiled for ARMv6 I suppose that we will have a perfomance loss running Raspbian into new RPI2.
Do we see a new "Raspian 2" compiled for new RPI 2 ARMv7 ?
Is more simple use the standard Debian Wheezy "armhf" with only a specific compiled kernel (with some patch, module and firmware specific for new RPI 2)

Thanks for any infos.

User avatar
DougieLawson
Posts: 35798
Joined: Sun Jun 16, 2013 11:19 pm
Location: Basingstoke, UK
Contact: Website Twitter

Re: RPI 2 : Raspbian or Debian "armhf" ?

Tue Feb 03, 2015 8:29 am

The question of how to handle ARMv6 mix'n'match with ARMv7 is nowhere close to being answered.

Whether to go with DebIan may be a sensible option. The problem is the A,B,A+ & B+ users will right royally screw their systems if they add DebIan repos to their systems. We've seen enough of that already when folk add the DebIan repos by mistake.
Note: Having anything humorous in your signature is completely banned on this forum. Wear a tin-foil hat and you'll get a ban.

Any DMs sent on Twitter will be answered next month.

This is a doctor free zone.

User avatar
croston
Posts: 702
Joined: Sat Nov 26, 2011 12:33 pm
Location: Blackpool
Contact: Website

Re: RPI 2 : Raspbian or Debian "armhf" ?

Tue Feb 03, 2015 8:42 am

It is only a matter of time until people post blogs and guides on how to install ARMV7 Debian on a RPi2. Beginners will try to run it on their 1st generation Pis, not realising there is a difference.

The ARMV6/ARMV7 support problems have not even started yet... :( Dougie will be up to 20,000 posts in no time as a resilt.

User avatar
DougieLawson
Posts: 35798
Joined: Sun Jun 16, 2013 11:19 pm
Location: Basingstoke, UK
Contact: Website Twitter

Re: RPI 2 : Raspbian or Debian "armhf" ?

Tue Feb 03, 2015 8:48 am

croston wrote:It is only a matter of time until people post blogs and guides on how to install ARMV7 Debian on a RPi2. Beginners will try to run it on their 1st generation Pis, not realising there is a difference.

The ARMV6/ARMV7 support problems have not even started yet... :( Dougie will be up to 20,000 posts in no time as a resilt.
I suspect you'll be up to your ears in forum posts when folk find RPi.GPIO isn't in DebIan. I'll guess that a special Raspberry repo will be needed in an ARMv7 armhf install to add those missing Foundation pieces.
Note: Having anything humorous in your signature is completely banned on this forum. Wear a tin-foil hat and you'll get a ban.

Any DMs sent on Twitter will be answered next month.

This is a doctor free zone.

User avatar
ambrosa
Posts: 7
Joined: Tue Feb 03, 2015 6:08 am
Location: Milan - Italy
Contact: Website

Re: RPI 2 : Raspbian or Debian "armhf" ?

Tue Feb 03, 2015 9:00 am

I suspect that having a single mixed ARMv6/ARMv7 Raspbian distro results in a problematic solution in a long time.

In my opinion the best way should be to have two different distros, i.e. "Raspbian 1" and "Raspbian 2" isolating their code.
But it's only my opinion.....

fruitoftheloom
Posts: 20477
Joined: Tue Mar 25, 2014 12:40 pm
Location: Delightful Dorset

Re: RPI 2 : Raspbian or Debian "armhf" ?

Tue Feb 03, 2015 9:04 am

Retired disgracefully.....

User avatar
slmaws
Posts: 32
Joined: Wed Nov 13, 2013 6:41 pm
Location: Poland
Contact: Website

Re: RPI 2 : Raspbian or Debian "armhf" ?

Tue Feb 03, 2015 9:31 am

DougieLawson wrote:
croston wrote:I suspect you'll be up to your ears in forum posts when folk find RPi.GPIO isn't in DebIan
This actually is not that big issue. You can always

Code: Select all

pip install RPi.GPIO
See my Raspberry Pi tips on http://rpitips.com

ShiftPlusOne
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5872
Joined: Fri Jul 29, 2011 5:36 pm
Location: The unfashionable end of the western spiral arm of the Galaxy

Re: RPI 2 : Raspbian or Debian "armhf" ?

Tue Feb 03, 2015 9:38 am

I've been playing around with debian armhf and it's not any faster. At least according to sysbench and mbw. There will definitely be applications where armv7 and NEON will make a huge difference, and it may make more sense to support those few applications in raspbian than to maintain a whole separate image when the performance isn't there. If anybody has any other kind of benchmark they want me to run, which could convince us otherwise, let me know.

Debian armhf:

Code: Select all

sysbench 0.4.12:  multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 4

Doing CPU performance benchmark

Threads started!
Done.

Maximum prime number checked in CPU test: 10000


Test execution summary:
    total time:                          78.0288s
    total number of events:              10000
    total time taken by event execution: 312.0507
    per-request statistics:
         min:                                 30.96ms
         avg:                                 31.21ms
         max:                                 52.71ms
         approx.  95 percentile:              31.46ms

Threads fairness:
    events (avg/stddev):           2500.0000/16.97
    execution time (avg/stddev):   78.0127/0.01

[email protected]:~# mbw 100
Long uses 4 bytes. Allocating 2*26214400 elements = 209715200 bytes of memory.
Using 262144 bytes as blocks for memcpy block copy test.
Getting down to business... Doing 10 runs per test.
0       Method: MEMCPY  Elapsed: 0.30636        MiB: 100.00000  Copy: 326.412 MiB/s
1       Method: MEMCPY  Elapsed: 0.30621        MiB: 100.00000  Copy: 326.571 MiB/s
2       Method: MEMCPY  Elapsed: 0.30618        MiB: 100.00000  Copy: 326.603 MiB/s
3       Method: MEMCPY  Elapsed: 0.30651        MiB: 100.00000  Copy: 326.249 MiB/s
4       Method: MEMCPY  Elapsed: 0.30653        MiB: 100.00000  Copy: 326.229 MiB/s
5       Method: MEMCPY  Elapsed: 0.30630        MiB: 100.00000  Copy: 326.478 MiB/s
6       Method: MEMCPY  Elapsed: 0.30630        MiB: 100.00000  Copy: 326.475 MiB/s
7       Method: MEMCPY  Elapsed: 0.30642        MiB: 100.00000  Copy: 326.346 MiB/s
8       Method: MEMCPY  Elapsed: 0.30634        MiB: 100.00000  Copy: 326.440 MiB/s
9       Method: MEMCPY  Elapsed: 0.30647        MiB: 100.00000  Copy: 326.291 MiB/s
AVG     Method: MEMCPY  Elapsed: 0.30636        MiB: 100.00000  Copy: 326.410 MiB/s
0       Method: DUMB    Elapsed: 0.19986        MiB: 100.00000  Copy: 500.363 MiB/s
1       Method: DUMB    Elapsed: 0.19951        MiB: 100.00000  Copy: 501.233 MiB/s
2       Method: DUMB    Elapsed: 0.19944        MiB: 100.00000  Copy: 501.417 MiB/s
3       Method: DUMB    Elapsed: 0.19937        MiB: 100.00000  Copy: 501.575 MiB/s
4       Method: DUMB    Elapsed: 0.19978        MiB: 100.00000  Copy: 500.556 MiB/s
5       Method: DUMB    Elapsed: 0.19927        MiB: 100.00000  Copy: 501.837 MiB/s
6       Method: DUMB    Elapsed: 0.19969        MiB: 100.00000  Copy: 500.786 MiB/s
7       Method: DUMB    Elapsed: 0.19920        MiB: 100.00000  Copy: 502.018 MiB/s
8       Method: DUMB    Elapsed: 0.19887        MiB: 100.00000  Copy: 502.851 MiB/s
9       Method: DUMB    Elapsed: 0.19980        MiB: 100.00000  Copy: 500.506 MiB/s
AVG     Method: DUMB    Elapsed: 0.19948        MiB: 100.00000  Copy: 501.313 MiB/s
0       Method: MCBLOCK Elapsed: 0.17932        MiB: 100.00000  Copy: 557.678 MiB/s
1       Method: MCBLOCK Elapsed: 0.17962        MiB: 100.00000  Copy: 556.722 MiB/s
2       Method: MCBLOCK Elapsed: 0.17949        MiB: 100.00000  Copy: 557.140 MiB/s
3       Method: MCBLOCK Elapsed: 0.17945        MiB: 100.00000  Copy: 557.246 MiB/s
4       Method: MCBLOCK Elapsed: 0.17968        MiB: 100.00000  Copy: 556.545 MiB/s
5       Method: MCBLOCK Elapsed: 0.17940        MiB: 100.00000  Copy: 557.401 MiB/s
6       Method: MCBLOCK Elapsed: 0.17948        MiB: 100.00000  Copy: 557.171 MiB/s
7       Method: MCBLOCK Elapsed: 0.17976        MiB: 100.00000  Copy: 556.307 MiB/s
8       Method: MCBLOCK Elapsed: 0.17948        MiB: 100.00000  Copy: 557.168 MiB/s
9       Method: MCBLOCK Elapsed: 0.17947        MiB: 100.00000  Copy: 557.196 MiB/s
AVG     Method: MCBLOCK Elapsed: 0.17951        MiB: 100.00000  Copy: 557.057 MiB/s
[email protected]:~#
Raspbian:

Code: Select all

[email protected]:~# sysbench --test=cpu --num-threads=4 run
sysbench 0.4.12:  multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 4

Doing CPU performance benchmark

Threads started!
Done.

Maximum prime number checked in CPU test: 10000


Test execution summary:
    total time:                          74.6837s
    total number of events:              10000
    total time taken by event execution: 298.6677
    per-request statistics:
         min:                                 29.65ms
         avg:                                 29.87ms
         max:                                 51.18ms
         approx.  95 percentile:              30.08ms

Threads fairness:
    events (avg/stddev):           2500.0000/15.59
    execution time (avg/stddev):   74.6669/0.01

[email protected]:~# mbw 100
Long uses 4 bytes. Allocating 2*26214400 elements = 209715200 bytes of memory.
Using 262144 bytes as blocks for memcpy block copy test.
Getting down to business... Doing 10 runs per test.
0       Method: MEMCPY  Elapsed: 0.26334        MiB: 100.00000  Copy: 379.733 MiB/s
1       Method: MEMCPY  Elapsed: 0.26330        MiB: 100.00000  Copy: 379.801 MiB/s
2       Method: MEMCPY  Elapsed: 0.26339        MiB: 100.00000  Copy: 379.667 MiB/s
3       Method: MEMCPY  Elapsed: 0.26332        MiB: 100.00000  Copy: 379.759 MiB/s
4       Method: MEMCPY  Elapsed: 0.26346        MiB: 100.00000  Copy: 379.570 MiB/s
5       Method: MEMCPY  Elapsed: 0.26317        MiB: 100.00000  Copy: 379.975 MiB/s
6       Method: MEMCPY  Elapsed: 0.26339        MiB: 100.00000  Copy: 379.669 MiB/s
7       Method: MEMCPY  Elapsed: 0.26334        MiB: 100.00000  Copy: 379.736 MiB/s
8       Method: MEMCPY  Elapsed: 0.26346        MiB: 100.00000  Copy: 379.564 MiB/s
9       Method: MEMCPY  Elapsed: 0.26326        MiB: 100.00000  Copy: 379.860 MiB/s
AVG     Method: MEMCPY  Elapsed: 0.26334        MiB: 100.00000  Copy: 379.733 MiB/s
0       Method: DUMB    Elapsed: 0.19957        MiB: 100.00000  Copy: 501.067 MiB/s
1       Method: DUMB    Elapsed: 0.19878        MiB: 100.00000  Copy: 503.059 MiB/s
2       Method: DUMB    Elapsed: 0.19928        MiB: 100.00000  Copy: 501.794 MiB/s
3       Method: DUMB    Elapsed: 0.19867        MiB: 100.00000  Copy: 503.347 MiB/s
4       Method: DUMB    Elapsed: 0.19847        MiB: 100.00000  Copy: 503.862 MiB/s
5       Method: DUMB    Elapsed: 0.19995        MiB: 100.00000  Copy: 500.130 MiB/s
6       Method: DUMB    Elapsed: 0.19876        MiB: 100.00000  Copy: 503.114 MiB/s
7       Method: DUMB    Elapsed: 0.19851        MiB: 100.00000  Copy: 503.763 MiB/s
8       Method: DUMB    Elapsed: 0.19906        MiB: 100.00000  Copy: 502.369 MiB/s
9       Method: DUMB    Elapsed: 0.19944        MiB: 100.00000  Copy: 501.401 MiB/s
AVG     Method: DUMB    Elapsed: 0.19905        MiB: 100.00000  Copy: 502.388 MiB/s
0       Method: MCBLOCK Elapsed: 0.15212        MiB: 100.00000  Copy: 657.358 MiB/s
1       Method: MCBLOCK Elapsed: 0.15185        MiB: 100.00000  Copy: 658.549 MiB/s
2       Method: MCBLOCK Elapsed: 0.15180        MiB: 100.00000  Copy: 658.762 MiB/s
3       Method: MCBLOCK Elapsed: 0.15178        MiB: 100.00000  Copy: 658.844 MiB/s
4       Method: MCBLOCK Elapsed: 0.15162        MiB: 100.00000  Copy: 659.544 MiB/s
5       Method: MCBLOCK Elapsed: 0.15184        MiB: 100.00000  Copy: 658.597 MiB/s
6       Method: MCBLOCK Elapsed: 0.15156        MiB: 100.00000  Copy: 659.792 MiB/s
7       Method: MCBLOCK Elapsed: 0.15193        MiB: 100.00000  Copy: 658.189 MiB/s
8       Method: MCBLOCK Elapsed: 0.15182        MiB: 100.00000  Copy: 658.688 MiB/s
9       Method: MCBLOCK Elapsed: 0.15165        MiB: 100.00000  Copy: 659.431 MiB/s
AVG     Method: MCBLOCK Elapsed: 0.15180        MiB: 100.00000  Copy: 658.775 MiB/s

ShiftPlusOne
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5872
Joined: Fri Jul 29, 2011 5:36 pm
Location: The unfashionable end of the western spiral arm of the Galaxy

Re: RPI 2 : Raspbian or Debian "armhf" ?

Tue Feb 03, 2015 9:39 am

I've been playing around with debian armhf and it's not any faster. At least according to sysbench and mbw. There will definitely be applications where armv7 and NEON will make a huge difference, and it may make more sense to support those few applications in raspbian than to maintain a whole separate image when the performance isn't there. If anybody has any other kind of benchmark they want me to run, which could convince us otherwise, let me know.

Debian armhf:

Code: Select all

sysbench 0.4.12:  multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 4

Doing CPU performance benchmark

Threads started!
Done.

Maximum prime number checked in CPU test: 10000


Test execution summary:
    total time:                          78.0288s
    total number of events:              10000
    total time taken by event execution: 312.0507
    per-request statistics:
         min:                                 30.96ms
         avg:                                 31.21ms
         max:                                 52.71ms
         approx.  95 percentile:              31.46ms

Threads fairness:
    events (avg/stddev):           2500.0000/16.97
    execution time (avg/stddev):   78.0127/0.01

[email protected]:~# mbw 100
Long uses 4 bytes. Allocating 2*26214400 elements = 209715200 bytes of memory.
Using 262144 bytes as blocks for memcpy block copy test.
Getting down to business... Doing 10 runs per test.
0       Method: MEMCPY  Elapsed: 0.30636        MiB: 100.00000  Copy: 326.412 MiB/s
1       Method: MEMCPY  Elapsed: 0.30621        MiB: 100.00000  Copy: 326.571 MiB/s
2       Method: MEMCPY  Elapsed: 0.30618        MiB: 100.00000  Copy: 326.603 MiB/s
3       Method: MEMCPY  Elapsed: 0.30651        MiB: 100.00000  Copy: 326.249 MiB/s
4       Method: MEMCPY  Elapsed: 0.30653        MiB: 100.00000  Copy: 326.229 MiB/s
5       Method: MEMCPY  Elapsed: 0.30630        MiB: 100.00000  Copy: 326.478 MiB/s
6       Method: MEMCPY  Elapsed: 0.30630        MiB: 100.00000  Copy: 326.475 MiB/s
7       Method: MEMCPY  Elapsed: 0.30642        MiB: 100.00000  Copy: 326.346 MiB/s
8       Method: MEMCPY  Elapsed: 0.30634        MiB: 100.00000  Copy: 326.440 MiB/s
9       Method: MEMCPY  Elapsed: 0.30647        MiB: 100.00000  Copy: 326.291 MiB/s
AVG     Method: MEMCPY  Elapsed: 0.30636        MiB: 100.00000  Copy: 326.410 MiB/s
0       Method: DUMB    Elapsed: 0.19986        MiB: 100.00000  Copy: 500.363 MiB/s
1       Method: DUMB    Elapsed: 0.19951        MiB: 100.00000  Copy: 501.233 MiB/s
2       Method: DUMB    Elapsed: 0.19944        MiB: 100.00000  Copy: 501.417 MiB/s
3       Method: DUMB    Elapsed: 0.19937        MiB: 100.00000  Copy: 501.575 MiB/s
4       Method: DUMB    Elapsed: 0.19978        MiB: 100.00000  Copy: 500.556 MiB/s
5       Method: DUMB    Elapsed: 0.19927        MiB: 100.00000  Copy: 501.837 MiB/s
6       Method: DUMB    Elapsed: 0.19969        MiB: 100.00000  Copy: 500.786 MiB/s
7       Method: DUMB    Elapsed: 0.19920        MiB: 100.00000  Copy: 502.018 MiB/s
8       Method: DUMB    Elapsed: 0.19887        MiB: 100.00000  Copy: 502.851 MiB/s
9       Method: DUMB    Elapsed: 0.19980        MiB: 100.00000  Copy: 500.506 MiB/s
AVG     Method: DUMB    Elapsed: 0.19948        MiB: 100.00000  Copy: 501.313 MiB/s
0       Method: MCBLOCK Elapsed: 0.17932        MiB: 100.00000  Copy: 557.678 MiB/s
1       Method: MCBLOCK Elapsed: 0.17962        MiB: 100.00000  Copy: 556.722 MiB/s
2       Method: MCBLOCK Elapsed: 0.17949        MiB: 100.00000  Copy: 557.140 MiB/s
3       Method: MCBLOCK Elapsed: 0.17945        MiB: 100.00000  Copy: 557.246 MiB/s
4       Method: MCBLOCK Elapsed: 0.17968        MiB: 100.00000  Copy: 556.545 MiB/s
5       Method: MCBLOCK Elapsed: 0.17940        MiB: 100.00000  Copy: 557.401 MiB/s
6       Method: MCBLOCK Elapsed: 0.17948        MiB: 100.00000  Copy: 557.171 MiB/s
7       Method: MCBLOCK Elapsed: 0.17976        MiB: 100.00000  Copy: 556.307 MiB/s
8       Method: MCBLOCK Elapsed: 0.17948        MiB: 100.00000  Copy: 557.168 MiB/s
9       Method: MCBLOCK Elapsed: 0.17947        MiB: 100.00000  Copy: 557.196 MiB/s
AVG     Method: MCBLOCK Elapsed: 0.17951        MiB: 100.00000  Copy: 557.057 MiB/s
[email protected]:~#
Raspbian:

Code: Select all

[email protected]:~# sysbench --test=cpu --num-threads=4 run
sysbench 0.4.12:  multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 4

Doing CPU performance benchmark

Threads started!
Done.

Maximum prime number checked in CPU test: 10000


Test execution summary:
    total time:                          74.6837s
    total number of events:              10000
    total time taken by event execution: 298.6677
    per-request statistics:
         min:                                 29.65ms
         avg:                                 29.87ms
         max:                                 51.18ms
         approx.  95 percentile:              30.08ms

Threads fairness:
    events (avg/stddev):           2500.0000/15.59
    execution time (avg/stddev):   74.6669/0.01

[email protected]:~# mbw 100
Long uses 4 bytes. Allocating 2*26214400 elements = 209715200 bytes of memory.
Using 262144 bytes as blocks for memcpy block copy test.
Getting down to business... Doing 10 runs per test.
0       Method: MEMCPY  Elapsed: 0.26334        MiB: 100.00000  Copy: 379.733 MiB/s
1       Method: MEMCPY  Elapsed: 0.26330        MiB: 100.00000  Copy: 379.801 MiB/s
2       Method: MEMCPY  Elapsed: 0.26339        MiB: 100.00000  Copy: 379.667 MiB/s
3       Method: MEMCPY  Elapsed: 0.26332        MiB: 100.00000  Copy: 379.759 MiB/s
4       Method: MEMCPY  Elapsed: 0.26346        MiB: 100.00000  Copy: 379.570 MiB/s
5       Method: MEMCPY  Elapsed: 0.26317        MiB: 100.00000  Copy: 379.975 MiB/s
6       Method: MEMCPY  Elapsed: 0.26339        MiB: 100.00000  Copy: 379.669 MiB/s
7       Method: MEMCPY  Elapsed: 0.26334        MiB: 100.00000  Copy: 379.736 MiB/s
8       Method: MEMCPY  Elapsed: 0.26346        MiB: 100.00000  Copy: 379.564 MiB/s
9       Method: MEMCPY  Elapsed: 0.26326        MiB: 100.00000  Copy: 379.860 MiB/s
AVG     Method: MEMCPY  Elapsed: 0.26334        MiB: 100.00000  Copy: 379.733 MiB/s
0       Method: DUMB    Elapsed: 0.19957        MiB: 100.00000  Copy: 501.067 MiB/s
1       Method: DUMB    Elapsed: 0.19878        MiB: 100.00000  Copy: 503.059 MiB/s
2       Method: DUMB    Elapsed: 0.19928        MiB: 100.00000  Copy: 501.794 MiB/s
3       Method: DUMB    Elapsed: 0.19867        MiB: 100.00000  Copy: 503.347 MiB/s
4       Method: DUMB    Elapsed: 0.19847        MiB: 100.00000  Copy: 503.862 MiB/s
5       Method: DUMB    Elapsed: 0.19995        MiB: 100.00000  Copy: 500.130 MiB/s
6       Method: DUMB    Elapsed: 0.19876        MiB: 100.00000  Copy: 503.114 MiB/s
7       Method: DUMB    Elapsed: 0.19851        MiB: 100.00000  Copy: 503.763 MiB/s
8       Method: DUMB    Elapsed: 0.19906        MiB: 100.00000  Copy: 502.369 MiB/s
9       Method: DUMB    Elapsed: 0.19944        MiB: 100.00000  Copy: 501.401 MiB/s
AVG     Method: DUMB    Elapsed: 0.19905        MiB: 100.00000  Copy: 502.388 MiB/s
0       Method: MCBLOCK Elapsed: 0.15212        MiB: 100.00000  Copy: 657.358 MiB/s
1       Method: MCBLOCK Elapsed: 0.15185        MiB: 100.00000  Copy: 658.549 MiB/s
2       Method: MCBLOCK Elapsed: 0.15180        MiB: 100.00000  Copy: 658.762 MiB/s
3       Method: MCBLOCK Elapsed: 0.15178        MiB: 100.00000  Copy: 658.844 MiB/s
4       Method: MCBLOCK Elapsed: 0.15162        MiB: 100.00000  Copy: 659.544 MiB/s
5       Method: MCBLOCK Elapsed: 0.15184        MiB: 100.00000  Copy: 658.597 MiB/s
6       Method: MCBLOCK Elapsed: 0.15156        MiB: 100.00000  Copy: 659.792 MiB/s
7       Method: MCBLOCK Elapsed: 0.15193        MiB: 100.00000  Copy: 658.189 MiB/s
8       Method: MCBLOCK Elapsed: 0.15182        MiB: 100.00000  Copy: 658.688 MiB/s
9       Method: MCBLOCK Elapsed: 0.15165        MiB: 100.00000  Copy: 659.431 MiB/s
AVG     Method: MCBLOCK Elapsed: 0.15180        MiB: 100.00000  Copy: 658.775 MiB/s

User avatar
DougieLawson
Posts: 35798
Joined: Sun Jun 16, 2013 11:19 pm
Location: Basingstoke, UK
Contact: Website Twitter

Re: RPI 2 : Raspbian or Debian "armhf" ?

Tue Feb 03, 2015 10:03 am

slmaws wrote:
DougieLawson wrote:
croston wrote:I suspect you'll be up to your ears in forum posts when folk find RPi.GPIO isn't in DebIan
This actually is not that big issue. You can always

Code: Select all

pip install RPi.GPIO
You can do that, I can do that, but your average regular new user who's just got their first Raspberry Pi won't be able to do that. We see that sort of behaviour everyday on the forum.

Hanlon's Razor springs to mind. http://en.wikipedia.org/wiki/Hanlon%27s_razor
Note: Having anything humorous in your signature is completely banned on this forum. Wear a tin-foil hat and you'll get a ban.

Any DMs sent on Twitter will be answered next month.

This is a doctor free zone.

User avatar
slmaws
Posts: 32
Joined: Wed Nov 13, 2013 6:41 pm
Location: Poland
Contact: Website

Re: RPI 2 : Raspbian or Debian "armhf" ?

Tue Feb 03, 2015 10:14 am

DougieLawson wrote: You can do that, I can do that, but your average regular new user who's just got their first Raspberry Pi won't be able to do that. We see that sort of behaviour everyday on the forum.

Hanlon's Razor springs to mind. http://en.wikipedia.org/wiki/Hanlon%27s_razor
Ok, good point :)
See my Raspberry Pi tips on http://rpitips.com

Havinit
Posts: 52
Joined: Sat Feb 09, 2013 12:34 pm

Re: RPI 2 : Raspbian or Debian "armhf" ?

Tue Feb 03, 2015 10:19 am

For my part, I'm certain that one way or another we'll see a distro tailored to the RPi2's enhancements (or should we call it the Area? Little geometry humour there :lol: ), whether it's Raspbian or another, and "blessed" by the RPF. I just hope it's not Windows... :shock:

Debian caters to multiple arches, so surely Raspbian can too, within a single distro. Making an entirely separate "Raspbian2" (or does that sound too much like Gentoo?) would probably be more of a duplication of effort. (I take the point about separate images though, and yes I hope that branding makes it abundantly clear to n00bs which one they should put on their device, to save Dougie et al. some headaches.)

I just hope there's still a distro that brings a free copy of Mathematica, personally: that should go like stink on the Pi2 :D

PuppetHoundZ
Posts: 170
Joined: Wed Jan 21, 2015 2:57 am

Re: RPI 2 : Raspbian or Debian "armhf" ?

Wed Feb 04, 2015 12:22 am

I think two distros will only cause more harm then good for children when it comes to Raspbian. The whole OS was designed for Children to use so having it unified is better and easier for the kid in the classroom. The Student would be able to take their SDCard from a PiB+ to a Pi2B and vice versa would be good when they are creating programs and projects. I'm sure not all classrooms will have the lastest Pi2B right away anyway so having a Universal OS that works on both is better. Two separate Raspbian distros will stink.

Maybe if there was a Non-recommended/ Developer focused version that used more specific Firmware for the new v7 like SNAPPY UBUNTU CORE would be the idea for those interested in having a Raspberry Pi 2 Exclusive OS. (I may not know what I'm talking about but the principal is there).

bust
Posts: 76
Joined: Mon Mar 17, 2014 12:31 am

Re: RPI 2 : Raspbian or Debian "armhf" ?

Wed Feb 04, 2015 4:26 am

Hi
@ShiftPlusOne
About:(I've been playing around with debian armhf and it's not any faster.)
Maybe if he will be able to explain to you more
The source that i build sources in distro version Armel on raspberry he are able to working as binary on armv7
I have an old cortex-a8 (only one core) and i can confirmed that with binary moved with only (softfp) , he work already more speed * 2 on the ARMv7.
I think that it's with armhf where he could be increased an very big work for move existing binary as compatible.
i must make test to see if natively armhf (objects *.o) are able to link on the cortex with linker flag (neon) .
I have an doubt that, with some parts (asm) are required, an new firmware to armhf will be able to solve problem of compatibility two sides easily.
I think when you want users are phished to work on unique hardware, he will result costing more expensive for his owner in the time,
this is known as the wolf is white.
The good new is GNU ld (GNU Binutils) 2.25 seem working compatible with precedent version (side ar as ranlib etc ...).
also with CLANG version 3.5.0 (tags/RELEASE_350/final).
I can confirm to you with no doubt that with ARMv7 you could have the results are largely better to all side your system
with flag NEON used or without used. Require just you wait a little that some libraries major are rebuild correctly better
(homogenous),(read about the problems (circular compile with shared *.so) you could understand more the problem of performance.
The new raspberry will be extraordinary ,largely more effective that the old,this one is sure.
Regards

ShiftPlusOne
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5872
Joined: Fri Jul 29, 2011 5:36 pm
Location: The unfashionable end of the western spiral arm of the Galaxy

Re: RPI 2 : Raspbian or Debian "armhf" ?

Wed Feb 04, 2015 10:09 am

Yeah, I've had a look at the sysbench source code and can see why there's no improvement:

Code: Select all

for(c=3; c < max_prime; c++)  
  {
    t = sqrt((double)c);
    for(l = 2; l <= t; l++)
      if (c % l == 0)
        break;
    if (l > t )
      n++; 
  }
Pretty sure that will compile down pretty similarly on armv6 and armv7, so it's not a very good benchmark for this.

bust
Posts: 76
Joined: Mon Mar 17, 2014 12:31 am

Re: RPI 2 : Raspbian or Debian "armhf" ?

Wed Feb 04, 2015 12:06 pm

Hi
As you have the two models in your hands , that he could be interesting is you mount
process (cluster) (distcc(d)) for verifying if he able to generate (object) in the shared side (v4 v6 & v7),
and linking after differently (specifically to the model processor) on side you where you call
(without forcefully it's used option (headers pump)) ,also without it's require driving manually
plugin linker (gold).is to see if able to work natively with Makefile of the packages source.
I want make but currently i am busy on a other side.
Regards

dev00
Posts: 2
Joined: Tue Jan 27, 2015 11:10 pm

Re: RPI 2 : Raspbian or Debian "armhf" ?

Wed Feb 04, 2015 5:06 pm

ShiftPlusOne wrote:Yeah, I've had a look at the sysbench source code and can see why there's no improvement:

Code: Select all

for(c=3; c < max_prime; c++)  
  {
    t = sqrt((double)c);
    for(l = 2; l <= t; l++)
      if (c % l == 0)
        break;
    if (l > t )
      n++; 
  }
Pretty sure that will compile down pretty similarly on armv6 and armv7, so it's not a very good benchmark for this.

This will not use processor SIMD instruction (NEON) because compiler will not vectorize it. This loop doesn't have needed construction for auto vectorizing.

RobHenry
Posts: 452
Joined: Fri Sep 21, 2012 9:04 pm
Location: UK

Re: RPI 2 : Raspbian or Debian "armhf" ?

Wed Feb 04, 2015 7:13 pm

What do I need to put in /etc/apt/sources.list to upgrade from raspbian to debain armhf?

Will leaving the contents of sources.list.d/raspi.list in place be enough to ensure I retain the foundation's kernel?

I just fancy doing this as an experiment on a pi 2 and have no concerns about breaking the system as I'm just playing about with a fresh install.

Thanks

bust
Posts: 76
Joined: Mon Mar 17, 2014 12:31 am

Re: RPI 2 : Raspbian or Debian "armhf" ?

Thu Feb 05, 2015 12:58 am

Hi

@ShiftPlusOne
I believe i understand your problem you don't have better result, require you rebuild manually your kernel
locally (without using cross compile)
In process build if you trace you will see at an step that (engine neon) will be detected automatically.
the problem with the installation (image) you can't select between several kernels specifically
optimized to your model processor.

@dev00 (hi)
I agree with you that same loop will be unable vectorized , but with cortex you have choice to use
VFP or NEON. In some case VFP will be required

you will read in documentation GCC subject (flags arm)

(If the selected floating-point hardware includes the NEON extension (e.g. -mfpu=neon),
note that floating-point operations are not generated by GCC's auto-vectorization pass
unless -funsafe-math-optimizations is also specified. This is because NEON hardware does
not fully implement the IEEE 754 standard for floating-point arithmetic
(in particular denormal values are treated as zero), so the use of NEON instructions may
lead to a loss of precision.)

@RobHenry (hi)
Council, do not merge several repository he will always result catastrophic to your system
It's more prudent you wait an little i think the team raspbian will serve in futures new update
perfectly improved with specificity added for your new raspberry

Regards

mstorsjo
Posts: 14
Joined: Thu Feb 21, 2013 9:43 pm

Re: RPI 2 : Raspbian or Debian "armhf" ?

Thu Feb 05, 2015 12:34 pm

Apps that can use NEON will in many cases already have runtime detection for it (e.g. on Android, the armeabi-v7a baseline does not include NEON so all such code needs to be runtime enabled) - in these cases, one single build will work just fine, and will give just about as good performance (as long as NEON code is built and included in the binary, even if built for an armv6 baseline). This is the same convention as used on x86 as well; a binary can contain MMX/SSE codepaths in many different versions, but they should only be used once a runtime detection has indicated that the cpu supports it. You don't start a new distribution just because there's a new version of the SSE instruction set.

E.g. libav/avconv works this way - since it knows it can runtime detect the cpu features, it will enable and build NEON codepaths as long as the assembler is able to assemble it, but only actually use it if the runtime detection shows it. I get a 10x speedup for software AAC/H264 decoding on the RPi2 compared to the RPi1, with the exact same binary running on both.

The only thing that is lost is the potential for compiler autovectorization, but for most packages where these things actually matter, it's already optimized with hand-written assembly or intrinsics.

So as long as care is taken that such optional optimizations are enabled and built in (which is mostly a build system/packaging issue), there shouldn't be too much of a downside of sticking to the current ARMv6 Raspbian. If I remember correctly, NEON is optional in Debian armhf as well, so all packages there should have autodetection for it (but I don't know whether this actually holds up for all packages or not, since there's not that many ARMv7 boards that lack NEON). The main issue probably is whether the optional codepaths get built at all when the baseline is ARMv6.

There may still of course be other reasons for wanting to go for normal armhf Debian. (For people interested in that, I assume most of you have seen http://sjoerd.luon.net/posts/2015/02/de ... e-on-rpi2/ already.)

diederik
Posts: 391
Joined: Wed Mar 26, 2014 11:17 pm

Re: RPI 2 : Raspbian or Debian "armhf" ?

Thu Feb 05, 2015 6:01 pm

mstorsjo wrote:There may still of course be other reasons for wanting to go for normal armhf Debian. (For people interested in that, I assume most of you have seen http://sjoerd.luon.net/posts/2015/02/de ... e-on-rpi2/ already.)
Do you more of such awesome links?

ssvb
Posts: 112
Joined: Sat May 19, 2012 6:15 pm

Re: RPI 2 : Raspbian or Debian "armhf" ?

Sun Feb 08, 2015 7:20 pm

The people interested in ARMv6 vs. ARMv7 differences can have a look at the ARM Architecture Reference Manual (yes, a free registration at the ARM website is required to actually download it). But in nutshell, the userland visible differences are just:
  1. Thumb2 support, which is good for code size reduction. But it is basically a different instructions encoding scheme for the same instructions and has no significant impact on performance (could either improve or regress it within a few percents).
  2. The DMB, DSB, ISB, PLI, SDIV, and UDIV instructions are added in ARMv7 and are not present in any form in ARMv6.
  3. Optional NEON in ARMv7 versus missing NEON in ARMv6. Which in practice means the same for the end users.
Moving to ARMv7 is not going to provide any groundbreaking performance improvements. The hand written NEON assembly is already runtime detected in both cases and automatically taken into use when run on a compatible CPU. Raspbian packages just need to be reviewed to ensure that they do not explicitly disable NEON support in such packages. Which, for example, seems to be the case for the raspbian pixman package.

bust
Posts: 76
Joined: Mon Mar 17, 2014 12:31 am

Re: RPI 2 : Raspbian or Debian "armhf" ?

Thu Feb 12, 2015 5:40 am

Hi
@mstorsjo
Thank for your explications and your link ,I agree with large part of your analyze but i afraid that he will be
more complex to improve perfectly with using v6 v7 no dissociated.
i know that is able to use auto detect (*runtime) but in all the system you can
count in the fingers of your hand the libraries that are able to manage correctly this way.
About auto vectorized:
Even if you write manually vector or you use OpenMp , threading etc ... with the flags of compiler are inappropriate ,
unfortunately, he will result more slow that without.
Improved perfectly or not, the Cortex hosted on new raspberry will give always result is better that
on old processor family 11.

Process auto vectorized not require you have Cortex with several cores obligatory he can work on
family 11 (1 core), it's only with hyper threading where he will use affinity (cores). thread is an child
of the (pid) not obligatory directly linked several forks of the semaphores.
Also you have (ipcs) that are perfectly able to improve on a single core family 11.
Currently i have only to my hands an old cortex-a8 one core i can not evaluate how is managed the spool queue
of (granularity) on Cortex with multiple cores

I don't want that real value of processor family 11 hosted on the precedent raspberry models will be incorrectly
interpreted with my poor english, this model processor have also several very good quality and he is
perfectly able to answer correctly all side of the system Linux complet.

About your reference when you compare with amd64 and x86, unfortunately with architecture Power? and Arm the flags
that you use ,are more sensitive and could large impact result. it's less flexible with the interpretation of "weird" flags inappropriate.

about *runtime (example between others ./configure some optional flags) mpg123-1.20.1 (mp3)

--with-cpu=generic[_fpu] Use generic processor code with floating point arithmetic
--with-cpu=generic_float Plain alias to generic_fpu now... float output is a normal runtime option!
--with-cpu=generic_nofpu Use generic processor code with fixed point arithmetic (p.ex. ARM)
--with-cpu=generic_dither Use generic processor code with floating point arithmetic and dithering for 1to1 16bit decoding.
--with-cpu=i386[_fpu] Use code optimized for i386 processors with floating point arithmetic
--with-cpu=i386_nofpu Use code optimized for i386 processors with fixed point arithmetic
--with-cpu=i486 Use code optimized for i486 processors (only usable alone!)
--with-cpu=i586 Use code optimized for i586 processors
--with-cpu=i586_dither Use code optimized for i586 processors with dithering (noise shaping), adds 256K to binary size
--with-cpu=3dnow Use code optimized for 3DNow processors
--with-cpu=3dnow_vintage Use code optimized for older 3DNow processors (K6 family)
--with-cpu=3dnowext Use code optimized for 3DNowExt processors (K6-3+, Athlon)
--with-cpu=3dnowext_alone Really only 3DNowExt decoder, without 3DNow fallback for flexible rate
--with-cpu=3dnow_vintage Use code optimized for older extended 3DNow processors (like K6-III+)
--with-cpu=mmx Use code optimized for MMX processors
--with-cpu=mmx_alone Really only MMX decoder, without i586 fallback for flexible rate
--with-cpu=sse Use code optimized for SSE processors
--with-cpu=sse_vintage Use code optimized for older SSE processors (plain C DCT36)
--with-cpu=sse_alone Really only SSE decoder, without i586 fallback for flexible rate
--with-cpu=avx Use code optimized for x86-64 with AVX processors
--with-cpu=x86 Pack all x86 opts into one binary (excluding i486, including dither)
--with-cpu=x86-64 Use code optimized for x86-64 processors (AMD64 and Intel64, including AVX and dithered generic)
--with-cpu=altivec Use code optimized for Altivec processors (PowerPC G4 and G5)
--with-cpu=ppc_nofpu Use code optimized for PowerPC processors with fixed point arithmetic
--with-cpu=neon Use code optimized for ARM NEON SIMD engine (Cortex-A series)
--with-cpu=arm_fpu Pack neon and generic[_dither] decoders, for ARM processors with FPU and/or NEON
--with-cpu=arm_nofpu Use code optimized for ARM processors with fixed point arithmetic
--with-cpu=neon64 Use code optimized for AArch64 NEON SIMD engine
--with-cpu=aarch64 Pack neon64 and generic[_dither] decoders, for 64bit ARM processors

About boot on fat16 or U-Boot
With U-Boot if i remember you must build with new config file (image kernel on raw sectors) if you want change
the file system on stick or hd could answer to /dev/sdb?

@ssvb
About:
(Moving to ARMv7 is not going to provide any groundbreaking performance improvements.)
Yes but only if you have some the sources packages that are not specifically built with neon flags selected.
he exist only an insignificant part of the packages that are able to exploit runtime with a facultative assember
detected automatically.
you under estimate the capacity of improved that could be by managed the compiler and the linker with package
where are no used the assembler language.
When you have some part of packages side xorg ( X11) working on three legged, indeed he will be difficult
to improve performance.
I understand rather that he could be better to wait jessie that use packages more recent for not do work two times..

About options flags (pixman-0.32.6) which is a drop of water in the sea on the all an system.

--disable-libtool-lock avoid locking (might break parallel builds)
--disable-openmp do not use OpenMP
--disable-loongson-mmi disable Loongson MMI fast paths
--disable-mmx disable x86 MMX fast paths
--disable-sse2 disable SSE2 fast paths
--disable-ssse3 disable SSSE3 fast paths
--disable-vmx disable VMX fast paths
--disable-arm-simd disable ARM SIMD fast paths
--disable-arm-neon disable ARM NEON fast paths
--disable-arm-iwmmxt disable ARM IWMMXT fast paths
--disable-arm-iwmmxt2 build ARM IWMMXT fast paths with -march=iwmmxt
instead of -march=iwmmxt2
--disable-mips-dspr2 disable MIPS DSPr2 fast paths
--disable-gcc-inline-asm
disable GNU-style inline assembler
--enable-static-testprogs
build test programs as static binaries [default=no]
--enable-timers enable TIMER_BEGIN and TIMER_END macros [default=no]
--enable-gtk enable tests using GTK+ [default=auto]
--enable-libpng Build support for libpng (default: auto)


If you give pessimistic image for the new hardware that is largely more power , he will be difficult to stimulate the evolution
of the software with a alignment improved.

Regards

ssvb
Posts: 112
Joined: Sat May 19, 2012 6:15 pm

Re: RPI 2 : Raspbian or Debian "armhf" ?

Thu Feb 12, 2015 6:22 am

@bust

Not every application or library can benefit from SIMD optimizations. And such software typically already has hand written x86 SSE2/SSEE3/AVX or ARM NEON assembly/intrinsics.

After many years of compiler technology improvements, autovectorization is still providing rather disappointing results. Feel free to prove me wrong and demonstrate any real application, where using autovectorization actually makes sense.

bust
Posts: 76
Joined: Mon Mar 17, 2014 12:31 am

Re: RPI 2 : Raspbian or Debian "armhf" ?

Thu Feb 12, 2015 3:41 pm

Hi
About:
(Not every application or library can benefit from SIMD optimizations.)
Probably you don't understand my explication with my bad English
The problem is the part existing of libraries that are able to manage (SIMD optimizations) are
insignificant proportionally on all the system complete

About:
(After many years of compiler technology improvements, autovectorization is still providing
rather disappointing results.)

The vectorization is used only to divide a task complete in multiple asynchronous distributed .
Only the programing specifically written to it could give improvement. When you have the multiples
factors have dependency in the loop he will wait obligated even when he working on an other threads.
Also i think that we wait too of real enhancement for the improvement will be significant with him.


About:
(Feel free to prove me wrong and demonstrate any real application, where using auto vectorization actually
makes sense.)

For improve really you need rebuild large part of libraries hosted on system before you observe
real changes, if you have some shared libraries are not optimized homogenous he will be difficult to see
the changes with testing simultaneous (with and without vectors optimized) with reference based on a unique program
that not work only one.

Currently i work on the raspberry and i have very very good result, some problem persist but i work on
and I hope will be solved shortly.

Without judgement (An little bothered with an udev-182 standalone) and some new packages require systemd
that hosted more recent version udev included)
(By example last Weston 1.7 seem require recent udev on systemd)
I don't know if using method crafts (udev-lfs-197-2) he will be able to solve ?
Regards

Return to “Raspbian”