On Friday 16 July 2010 07:58:02 Paul Brook wrote:
> Mainly that your analysis of the code was almost entirely bogus.
You are free of course to take my analysis any way you like -btw it wasn't an
analysis, it was just an indication of the possible performance hit on softfp,
I'm sure you know the
> > Do the math, there are 6 more vmov instructions (all between rX and sX
> > registers) in the softfp versions. Ok, if one gives a stall of 20 cycles,
> > how many cycles do we lose in sinf() alone?
> So, what exactly did you want to prove?
Mainly that your analysis of the code was almost enti
On Friday 16 July 2010 07:14:17 Konstantinos Margaritis wrote:
> No comment needed. Such results are consistent with all math functions that
> I have tested (cosf, tanf, expf, etc). Speed gain is accumulative, so in
> say a rotation matrix function, with (usually) 2 cosf+2 sinf calls, the
> spee
Oh, btw, I also had done some benchmarking -much more elaborate than yours,
I'm afraid- when rewriting these functions using another algorithm (Pade
approximants, but that's not the discussion here):
0..M_PI/4
hardfp: 3184713.38 calculations of sinf()/sec
softfp: 3039513.68 calculations of sinf
On Friday 16 July 2010 00:29:27 Paul Brook wrote:
> A simple benchmark confirms this hypothesis.
> softfp is actually faster in many cases.
If you want to do a benchmark on sinf, next time do it right, span the values
on 0..M_PI at least (not 0..1.0), here are the results with only one change:
Hello Loïc,
2010/7/15, Loïc Minier :
> Concerning the triplet choice, I'd highly recommend reading this
> upstream thread:
> http://gcc.gnu.org/ml/gcc/2010-07/threads.html#00179
Thanks for sharing it. Quite interesting.
For my point of view, ABI should not be encoded in the upstream
triple
Dear developers,
2010/7/13, Riku Voipio :
> Subarchs could also be useful if we wanted to build softfp abi compatible
> armv6/armv7 armel builds of the whole debian repository. Of course we could
> do
> builds without subarchs, but then users would be unable distinguish which
> installed packages
+++ Matt Sealey [2010-07-15 16:39 -0500]:
> Hi Paul
>
> Please understand we know what we're talking about here :D
And so does Paul :-)
> In summary:
>
> soft
> * FPU is all emulated. FPU work is done in integer registers.
>
> softfp+vfp
> * actual FPU used, FPU argument passing done in intege
> > > > Do the math, there are 6 more vmov instructions (all between rX and
> > > > sX registers) in the softfp versions. Ok, if one gives a stall of 20
> > > > cycles, how many cycles do we lose in sinf() alone?
> > >
> > > Depends how the function is called. Worst case we loose 17 cycles, best
>
+++ Paul Brook [2010-07-15 22:29 +0100]:
> > > Do the math, there are 6 more vmov instructions (all between rX and sX
> > > registers) in the softfp versions. Ok, if one gives a stall of 20 cycles,
> > > how many cycles do we lose in sinf() alone?
> >
> > Depends how the function is called. Worst
> As Konstantinos explained, this is something of the order of 6 moves
> around from integer to float and back again for a relatively simple
> function like sinf() which takes one floating point argument and
> returns one. vmov rN, sN has a penalty of around 20 cycles. Nothing is
> being done here,
port name = "hardthumb"? "thumbhard"? thumbh? hthumb? :)
I dunno. I am just trying to get this into a spot where we can make a
decision. I know Lucid went all Thumb2 but does that mean Debian
should too?
The rest of the variables stay the same: still hardfloat, still
armv7-a as an architecture, s
On Thu, Jul 15, 2010 at 1:11 PM, Paul Brook wrote:
>> Lets take a step back on the naming.
>>
>> Let's say for example that we decide to use the fact that ThumbEE is a
>> required component on the ARMv7-A profile.
>>
>> My qualm with Thumb code on ARM is that it requires all libraries and
>> execu
Hi Paul
Please understand we know what we're talking about here :D
In summary:
We want a new port that uses the hard floating point version of the
EABI - floating point arguments to functions are passed in floating
point registers (sN, dN, qN) as the ABI allows.
This is to get around the fact t
Hello list,
i would like to boot my Thecus N2100 NAS from USB-Flash-Drive.
Maybe somebody could explain me how to customize the boot images etc.
The advantage I see is that I could spin down the data hard disks during
they are not in use.
Maybe it would be good to implement this feature direc
> > In libm.so, I took sinf() -a very often used function, absolutely
> > necessary for any trig stuff- and tried to actually find the differences
> > using
> >
> > objdump:
> >...
> >
> > Do the math, there are 6 more vmov instructions (all between rX and sX
> > registers) in the softfp versions.
> In libm.so, I took sinf() -a very often used function, absolutely necessary
> for any trig stuff- and tried to actually find the differences using
> objdump:
>...
> Do the math, there are 6 more vmov instructions (all between rX and sX
> registers) in the softfp versions. Ok, if one gives a stall
On Thursday 15 July 2010 18:20:07 Konstantinos Margaritis wrote:
> On Thursday 15 July 2010 17:34:01 Martin Guy wrote:
> > I still doubt that the disruption and extra work for the community of
> > Debian package maintainers, and the lower quality of the resulting
> > archive, is worth the small inc
> On Thursday 15 July 2010 21:11:50 Paul Brook wrote:
> > Choice of ISA is independent of the ABI. Generally speaking ARM code is
> >
> > still faster. This is another instance of where you want multiple
> > builds of the same package within the same port, so users can choose
> > between
> >
> > Switching to the hard-float ABI certainly does give some benefit. While
> > 20% isn't a trivial difference, it's important to keep this in context.
> > This is on top of what I'd guess is a 10x (i.e. 1000%) speedup achieved
> > without breaking the ABI and requiring a whole new port.
>
> How
> > What you're describing here is multiarch.
>
> Multiarch still isn't there, even after at least 5 years when I saw the
> first presentation. It may have been hard on x86/x86_64 or ppc/ppc64 where
> there were only 2 variants, here we have what? 5? 10? I seriously think
> it's not worth it.
No.
On Thursday 15 July 2010 21:11:50 Paul Brook wrote:
> Choice of ISA is independent of the ABI. Generally speaking ARM code is
> still faster. This is another instance of where you want multiple builds
> of the same package within the same port, so users can choose between
> speed (-marm -O2) and
On Thu, Jul 15, 2010, Matt Sealey wrote:
> Let's say we said, the new port will be based on the Thumb ISA as in
> the ARMv7-A and depdenent on that profile, could we call it "thumb" or
> "thumbee" or so and remove the differentiation on arm and armel by the
> fact that it's built for this new impro
On Thu, Jul 15, 2010, Aurelien Jarno wrote:
>It allows
> to provide different versions of a given symbol using an IFUNC symbol
> type. This will be resolved by the dynamic loader during relocation
> depending on the hardware characteri
On Thursday 15 July 2010 21:06:52 Paul Brook wrote:
> Not quite. It provides a mechanism for selecting different routines without
> the runtime overhead of a check on every call. It effecitvely provides a
> hook into the dynamaic linker that allows you to decide which function to
> export for a
> Lets take a step back on the naming.
>
> Let's say for example that we decide to use the fact that ThumbEE is a
> required component on the ARMv7-A profile.
>
> My qualm with Thumb code on ARM is that it requires all libraries and
> executables to be compiled with a compatible ABI in the first
> On Thursday 15 July 2010 19:48:43 Aurelien Jarno wrote:
> > Note that the new alternative to hwcap is called "multiarch" in the GNU
> > libc (something totally different than "multiarch" in Debian). It allows
> > to provide different versions of a given symbol using an IFUNC symbol
> > type. This
On Thu, Jul 15, 2010 at 08:06:42PM +0300, Konstantinos Margaritis wrote:
> On Thursday 15 July 2010 19:48:43 Aurelien Jarno wrote:
> > Note that the new alternative to hwcap is called "multiarch" in the GNU
> > libc (something totally different than "multiarch" in Debian). It allows
> > to provide
Lets take a step back on the naming.
Let's say for example that we decide to use the fact that ThumbEE is a
required component on the ARMv7-A profile.
My qualm with Thumb code on ARM is that it requires all libraries and
executables to be compiled with a compatible ABI in the first place.
This me
On Thursday 15 July 2010 19:48:43 Aurelien Jarno wrote:
> Note that the new alternative to hwcap is called "multiarch" in the GNU
> libc (something totally different than "multiarch" in Debian). It allows
> to provide different versions of a given symbol using an IFUNC symbol
> type. This will be r
Riku Voipio a écrit :
> On Thu, Jul 08, 2010 at 01:06:58PM +0200, Guillem Jover wrote:
>> Personally, before any further discussion I'd like to see some numbers
>> with core libraries (libc, libgcc, libgmp, libatlas? etc) built with
>> softfp, which eventually might be able to switch to use the hwc
On Thu, Jul 15, 2010 at 11:19 AM, Paul Brook wrote:
>> > Enabling use of VFP does not require use of the hard-float ABI. Please
>> > don't confuse the two.
>>
>> The whole point of the port is that we get rid of the softfloat ABI in
>> order to use the VFP unit without playing around moving
>> reg
* Samuele Bianchi [2010-07-12 07:58]:
> [0 1 0]: Enable DMA mode
> Device 1 @ 0 1:
> Model: WDC WD1200BEVS-22RST0Firm: 04.01G04 Ser#:
> WD-WXE808NWD688
> Type: Hard Disk
> Supports 48-bit addressing
> Capacity: 114473.4 MB = 111.7 GB
On Thursday 15 July 2010 19:19:13 Paul Brook wrote:
> However changing the ABI doesn't solve many of the underlying problem.
> Specifically how to provide optimized binaries that take advantage of new
> features on modern CPUs while still supporting older hardware.
You can't bridge that gap. There
> > Enabling use of VFP does not require use of the hard-float ABI. Please
> > don't confuse the two.
>
> The whole point of the port is that we get rid of the softfloat ABI in
> order to use the VFP unit without playing around moving
> registers around. This sort of came about from Konstantinos'
On Thu, 15 Jul 2010 00:44:17 +0200
Hector Oron wrote:
> Hello Martin,
>
> 2010/7/15, Martin Michlmayr :
> > * Hector Oron [2010-07-14 22:54]:
> >> I would recommend you tag the bug as 'wontfix', as Debian does not
> >> fix stable release, but only provides security updates on the
> >> stable re
On Thu, Jul 15, 2010 at 10:26 AM, Paul Brook wrote:
>> On Thu, Jul 15, 2010 at 03:47:33PM +0100, Paul Brook wrote:
>> > > armel can also use vfp instructions, so I personally find it
>> > > confusing.
>> > Yes, however fixing this this does not require a new port. It only
>> > requires providi
> On Thu, Jul 15, 2010 at 03:47:33PM +0100, Paul Brook wrote:
> > > armel can also use vfp instructions, so I personally find it
> > > confusing.
> > Yes, however fixing this this does not require a new port. It only
> > requires providing alternative packages builds within the same port. The
>
On Thursday 15 July 2010 17:34:01 Martin Guy wrote:
> I still doubt that the disruption and extra work for the community of
> Debian package maintainers, and the lower quality of the resulting
> archive, is worth the small increment in speed that is promised. I
> hope
30% *measured* (vs promised)
On Thu, Jul 15, 2010 at 04:58:29PM +0200, Loïc Minier wrote:
> First, i386 was a bad name (it should have been called x86, or ia32),
> let's not redo the same mistake.
Good point.
> Second, cortex is not a minimum CPU, it's a particular implementation.
> Cortex-A implies ARMv7, but you can b
On Thu, Jul 15, 2010, Lennart Sorensen wrote:
> How is that different than i386 works on i686? The name is essentially
> the minimum cpu that can run the code.
First, i386 was a bad name (it should have been called x86, or ia32),
let's not redo the same mistake.
Second, cortex is not a minim
On Thu, Jul 15, 2010, Martin Guy wrote:
> No it can't. Any binary that contains a vfp instruction will die with
> SIGILL on any armv4t chip that has no vfp cpu, so cannot be used in
> Debian armel.
Yes, it will die /on chips without a VFP/, but Ubuntu has an armel port
with vfp turned on by defa
On Thu, Jul 15, 2010 at 03:47:33PM +0100, Paul Brook wrote:
> Yes, however fixing this this does not require a new port. It only requires
> providing alternative packages builds within the same port. The important
> point being that (assuming capable hardware) you can freely mix the two.
It soun
> On 7/15/10, Loïc Minier wrote:
> > armel can also use vfp instructions, so I personally find it confusing.
>
> No it can't. Any binary that contains a vfp instruction will die with
> SIGILL on any armv4t chip that has no vfp cpu, so cannot be used in
> Debian armel.
Yes, however fixing this
On Thu, Jul 15, 2010 at 10:00:28AM +0200, Loïc Minier wrote:
> cortex as the port name sounds very wrong, as others have commented
> already:
> * some CPUs we explicitly targe t(by configuring for vfpv3-d16) aren't
>cortex (they don't instantiate the Cortex-A8 gates on the silicon,
>but
On 7/15/10, Loïc Minier wrote:
> armel can also use vfp instructions, so I personally find it confusing.
No it can't. Any binary that contains a vfp instruction will die with
SIGILL on any armv4t chip that has no vfp cpu, so cannot be used in
Debian armel.
As far as the ABI is concerned, the ne
+++ Loïc Minier [2010-07-15 10:00 +0200]:
> On Wed, Jul 14, 2010, Hector Oron wrote:
> > Genesi have recommended 'cortex' as Debian architecture name and
> > 'arm-hardfloat-linux-gnueabi' as triplet. This has been in fact
> > approved and endorsed -and actually encouraged- by ARM itself, they
> > r
On Wed, Jul 14, 2010, Hector Oron wrote:
> Genesi have recommended 'cortex' as Debian architecture name and
> 'arm-hardfloat-linux-gnueabi' as triplet. This has been in fact
> approved and endorsed -and actually encouraged- by ARM itself, they
> really liked the idea of having a debian-cortex port.
Hello,
2010/7/15, Paul Brook :
> It isn't. "Cortex" is the marketing name for the current set of CPU core
> implementations designed by ARM ltd. Calling the armv7 port "cortex" is
> equivalent to calling the i686 port "pentium" [1].
But i?86 is ABI compatible, while ARM ABI is a full mess AFAICS
49 matches
Mail list logo
