Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #59619 > unrolled thread

Does each core of 8-core Intel processor has an independent floating X87 unit?

Back to article view | Back to comp.lang.c

Contents

  Does each core of 8-core Intel processor has an independent floating X87 unit? Weng Tianxiang <wtxwtx@gmail.com> - 2015-04-05 06:50 -0700
    Re: Does each core of 8-core Intel processor has an independent floating X87 unit? Noob <root@127.0.0.1> - 2015-04-05 17:17 +0200
      Re: Does each core of 8-core Intel processor has an independent floating X87 unit? Melzzzzz <mel@zzzzz.com> - 2015-04-05 17:35 +0200
        Re: Does each core of 8-core Intel processor has an independent floating X87 unit? BGB <cr88192@hotmail.com> - 2015-04-05 11:21 -0500
          Re: Does each core of 8-core Intel processor has an independent floating X87 unit? Melzzzzz <mel@zzzzz.com> - 2015-04-05 18:40 +0200
            Re: Does each core of 8-core Intel processor has an independent floating X87 unit? BGB <cr88192@hotmail.com> - 2015-04-05 11:56 -0500
              Re: Does each core of 8-core Intel processor has an independent floating X87 unit? fir <profesor.fir@gmail.com> - 2015-04-05 10:08 -0700
                Re: Does each core of 8-core Intel processor has an independent floating X87 unit? BGB <cr88192@hotmail.com> - 2015-04-05 13:17 -0500
                  Re: Does each core of 8-core Intel processor has an independent floating X87 unit? David Brown <david.brown@hesbynett.no> - 2015-04-07 10:10 +0200
                    Re: Does each core of 8-core Intel processor has an independent floating X87 unit? BGB <cr88192@hotmail.com> - 2015-04-07 10:26 -0500
                      Re: Does each core of 8-core Intel processor has an independent floating X87 unit? David Brown <david.brown@hesbynett.no> - 2015-04-07 23:40 +0200
                        Re: Does each core of 8-core Intel processor has an independent floating X87 unit? Bartc <bc@freeuk.com> - 2015-04-07 23:06 +0100
                          Re: Does each core of 8-core Intel processor has an independent floating X87 unit? David Brown <david.brown@hesbynett.no> - 2015-04-08 01:23 +0200
                            Re: Does each core of 8-core Intel processor has an independent floating X87 unit? BGB <cr88192@hotmail.com> - 2015-04-07 23:15 -0500
                        Re: Does each core of 8-core Intel processor has an independent floating X87 unit? BGB <cr88192@hotmail.com> - 2015-04-07 20:16 -0500
                          Re: Does each core of 8-core Intel processor has an independent floating X87 unit? David Brown <david.brown@hesbynett.no> - 2015-04-08 09:27 +0200
                            Re: Does each core of 8-core Intel processor has an independent floating X87 unit? BGB <cr88192@hotmail.com> - 2015-04-08 09:44 -0500
              Re: Does each core of 8-core Intel processor has an independent floating X87 unit? Melzzzzz <mel@zzzzz.com> - 2015-04-05 19:37 +0200
                Re: Does each core of 8-core Intel processor has an independent floating X87 unit? BGB <cr88192@hotmail.com> - 2015-04-05 18:50 -0500
                  Re: Does each core of 8-core Intel processor has an independent floating X87 unit? Robert Wessel <robertwessel2@yahoo.com> - 2015-04-05 22:29 -0500
                    Re: Does each core of 8-core Intel processor has an independent floating X87 unit? BGB <cr88192@hotmail.com> - 2015-04-05 23:09 -0500
                      Re: Does each core of 8-core Intel processor has an independent floating X87 unit? Robert Wessel <robertwessel2@yahoo.com> - 2015-04-06 01:54 -0500
                        Re: Does each core of 8-core Intel processor has an independent floating X87 unit? BGB <cr88192@hotmail.com> - 2015-04-06 07:44 -0500
                Re: Does each core of 8-core Intel processor has an independent floating X87 unit? David Brown <david.brown@hesbynett.no> - 2015-04-07 10:16 +0200
                  Re: Does each core of 8-core Intel processor has an independent floating X87 unit? Robert Wessel <robertwessel2@yahoo.com> - 2015-04-07 03:32 -0500
                    Re: Does each core of 8-core Intel processor has an independent floating X87 unit? David Brown <david.brown@hesbynett.no> - 2015-04-07 12:48 +0200
                      Re: Does each core of 8-core Intel processor has an independent floating X87 unit? Richard Heathfield <rjh@cpax.org.uk> - 2015-04-07 11:57 +0100
                        Re: Does each core of 8-core Intel processor has an independent floating X87 unit? David Brown <david.brown@hesbynett.no> - 2015-04-07 13:33 +0200
                        Re: Does each core of 8-core Intel processor has an independent floating X87 unit? Robert Wessel <robertwessel2@yahoo.com> - 2015-04-07 15:21 -0500
                    Re: Does each core of 8-core Intel processor has an independent floating X87 unit? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-04-07 17:15 +0000
                      Re: Does each core of 8-core Intel processor has an independent floating X87 unit? Tim Prince <tprince@computer.org> - 2015-04-07 14:21 -0400
              Re: Does each core of 8-core Intel processor has an independent floating X87 unit? Keith Thompson <kst-u@mib.org> - 2015-04-05 13:08 -0700
                Re: Does each core of 8-core Intel processor has an independent floating X87 unit? BGB <cr88192@hotmail.com> - 2015-04-05 15:27 -0500
            Re: Does each core of 8-core Intel processor has an independent floating X87 unit? Noob <root@127.0.0.1> - 2015-04-05 19:04 +0200
              Re: Does each core of 8-core Intel processor has an independent floating X87 unit? Melzzzzz <mel@zzzzz.com> - 2015-04-05 19:38 +0200
                Re: Does each core of 8-core Intel processor has an independent floating X87 unit? fir <profesor.fir@gmail.com> - 2015-04-05 10:46 -0700
              Re: Does each core of 8-core Intel processor has an independent floating X87 unit? Keith Thompson <kst-u@mib.org> - 2015-04-05 13:12 -0700
          Re: Does each core of 8-core Intel processor has an independent floating X87 unit? fir <profesor.fir@gmail.com> - 2015-04-05 09:51 -0700
            Re: Does each core of 8-core Intel processor has an independent floating X87 unit? BGB <cr88192@hotmail.com> - 2015-04-05 12:18 -0500
        Re: Does each core of 8-core Intel processor has an independent floating X87 unit? jacobnavia <jacob@jacob.remcomp.fr> - 2015-04-06 01:30 +0200
          Re: Does each core of 8-core Intel processor has an independent floating X87 unit? BGB <cr88192@hotmail.com> - 2015-04-05 19:27 -0500
            Re: Does each core of 8-core Intel processor has an independent floating X87 unit? christian.bau@cbau.wanadoo.co.uk - 2015-04-07 23:58 -0700
              Re: Does each core of 8-core Intel processor has an independent floating X87 unit? BGB <cr88192@hotmail.com> - 2015-04-08 08:08 -0500
          Re: Does each core of 8-core Intel processor has an independent floating X87 unit? Melzzzzz <mel@zzzzz.com> - 2015-04-06 03:36 +0200
          Re: Does each core of 8-core Intel processor has an independent floating X87 unit? David Brown <david.brown@hesbynett.no> - 2015-04-07 10:27 +0200
            Re: Does each core of 8-core Intel processor has an independent floating X87 unit? BGB <cr88192@hotmail.com> - 2015-04-07 10:39 -0500
          Re: Does each core of 8-core Intel processor has an independent floating X87 unit? christian.bau@cbau.wanadoo.co.uk - 2015-04-07 23:47 -0700
      Re: Does each core of 8-core Intel processor has an independent floating X87 unit? BGB <cr88192@hotmail.com> - 2015-04-05 11:04 -0500
        Re: Does each core of 8-core Intel processor has an independent floating X87 unit? Melzzzzz <mel@zzzzz.com> - 2015-04-05 18:20 +0200
          Re: Does each core of 8-core Intel processor has an independent floating X87 unit? BGB <cr88192@hotmail.com> - 2015-04-05 11:43 -0500
        Re: Does each core of 8-core Intel processor has an independent floating X87 unit? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-04-05 20:28 +0000
          Re: Does each core of 8-core Intel processor has an independent floating X87 unit? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-05 14:46 -0700
            Re: Does each core of 8-core Intel processor has an independent floating X87 unit? fir <profesor.fir@gmail.com> - 2015-04-05 15:01 -0700
      Re: Does each core of 8-core Intel processor has an independent floating X87 unit? Keith Thompson <kst-u@mib.org> - 2015-04-05 13:17 -0700
    Re: Does each core of 8-core Intel processor has an independent floating X87 unit? Paul <nospam@needed.com> - 2015-04-05 14:31 -0400
      Re: Does each core of 8-core Intel processor has an independent floating X87 unit? David Brown <david.brown@hesbynett.no> - 2015-04-07 11:01 +0200
    Re: Does each core of 8-core Intel processor has an independent floating X87 unit? Robert Wessel <robertwessel2@yahoo.com> - 2015-04-05 22:34 -0500
      Re: Does each core of 8-core Intel processor has an independent floating X87 unit? Weng Tianxiang <wtxwtx@gmail.com> - 2015-04-05 23:39 -0700
        Re: Does each core of 8-core Intel processor has an independent floating X87 unit? Robert Wessel <robertwessel2@yahoo.com> - 2015-04-06 02:06 -0500
          Re: Does each core of 8-core Intel processor has an independent floating X87 unit? BGB <cr88192@hotmail.com> - 2015-04-06 08:57 -0500
            Re: Does each core of 8-core Intel processor has an independent floating X87 unit? Robert Wessel <robertwessel2@yahoo.com> - 2015-04-06 12:38 -0500
              Re: Does each core of 8-core Intel processor has an independent floating X87 unit? BGB <cr88192@hotmail.com> - 2015-04-06 16:30 -0500
                Re: Does each core of 8-core Intel processor has an independent floating X87 unit? Stephen Sprunk <stephen@sprunk.org> - 2015-04-06 17:10 -0500
                  Re: Does each core of 8-core Intel processor has an independent floating   X87 unit? Ian Collins <ian-news@hotmail.com> - 2015-04-07 10:16 +1200
                    Re: Does each core of 8-core Intel processor has an independent floating   X87 unit? Melzzzzz <mel@zzzzz.com> - 2015-04-07 02:23 +0200
                  Re: Does each core of 8-core Intel processor has an independent floating X87 unit? BGB <cr88192@hotmail.com> - 2015-04-06 17:36 -0500
                Re: Does each core of 8-core Intel processor has an independent floating X87 unit? Robert Wessel <robertwessel2@yahoo.com> - 2015-04-06 17:41 -0500
                  Re: Does each core of 8-core Intel processor has an independent floating X87 unit? BGB <cr88192@hotmail.com> - 2015-04-06 20:09 -0500
                    Re: Does each core of 8-core Intel processor has an independent floating X87 unit? Richard Damon <Richard@Damon-Family.org> - 2015-04-06 22:44 -0400
                      Re: Does each core of 8-core Intel processor has an independent floating X87 unit? David Brown <david.brown@hesbynett.no> - 2015-04-07 11:11 +0200
          Re: Does each core of 8-core Intel processor has an independent floating X87 unit? Weng Tianxiang <wtxwtx@gmail.com> - 2015-04-06 08:04 -0700
            Re: Does each core of 8-core Intel processor has an independent floating X87 unit? Robert Wessel <robertwessel2@yahoo.com> - 2015-04-06 12:43 -0500
            Re: Does each core of 8-core Intel processor has an independent floating X87 unit? Paul <nospam@needed.com> - 2015-04-06 14:52 -0400
              Re: Does each core of 8-core Intel processor has an independent floating X87 unit? BGB <cr88192@hotmail.com> - 2015-04-06 17:09 -0500
        Re: Does each core of 8-core Intel processor has an independent floating X87 unit? Paul <nospam@needed.com> - 2015-04-06 11:11 -0400
          Re: Does each core of 8-core Intel processor has an independent floating X87 unit? Robert Wessel <robertwessel2@yahoo.com> - 2015-04-06 12:47 -0500
            Re: Does each core of 8-core Intel processor has an independent floating X87 unit? Stephen Sprunk <stephen@sprunk.org> - 2015-04-06 17:15 -0500
              Re: Does each core of 8-core Intel processor has an independent floating X87 unit? Robert Wessel <robertwessel2@yahoo.com> - 2015-04-07 03:41 -0500
                Re: Does each core of 8-core Intel processor has an independent floating X87 unit? Ian Collins <ian-news@hotmail.com> - 2015-04-07 21:19 +1200
                  Re: Does each core of 8-core Intel processor has an independent floating X87 unit? Stephen Sprunk <stephen@sprunk.org> - 2015-04-07 10:37 -0500
                    Re: Does each core of 8-core Intel processor has an independent floating   X87 unit? Tim Prince <tprince@computer.org> - 2015-04-07 12:13 -0400
                      Re: Does each core of 8-core Intel processor has an independent floating   X87 unit? Stephen Sprunk <stephen@sprunk.org> - 2015-04-09 12:34 -0500
                Re: Does each core of 8-core Intel processor has an independent floating X87 unit? Stephen Sprunk <stephen@sprunk.org> - 2015-04-07 10:48 -0500

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

#59670

(trying again, I think the first attempt was lost)


On 4/5/2015 6:30 PM, jacobnavia wrote:
 > Le 05/04/2015 17:35, Melzzzzz a écrit :
 >> On Sun, 05 Apr 2015 17:17:42 +0200
 >> Noob <root@127.0.0.1> wrote:
 >>
 >>>
 >>> And x87 is obsolete.
 >>>
 >>
 >> Who said that?
 >>
 > lcc-win was generating a fsin instruction to calculate the sin(x) using
 > the x87
 >
 > I was completely ASTONISHED that gcc was much faster. They had an
 > optimized sin routine in SSE and their routine was faster than a SINGLE
 > FPU instruction...
 >
 > Intel hasn't upgraded the x87 since at least 10-15 years...
 >
 > I still generate fsin though...

yeah...

a lot of these instructions can easily end up taking *hundreds* of CPU
cycles on recent processors.

in general, the performance of x87 instructions has also slipped pretty
badly in recent processors (whereas SSE has gotten relatively faster),
so if performance matters, it is often better to use SSE at this point.

[toc] | [prev] | [next] | [standalone]

#59790

On Monday, April 6, 2015 at 1:30:56 AM UTC+1, BGB wrote:
> a lot of these instructions can easily end up taking *hundreds* of CPU
> cycles on recent processors.
> 
> in general, the performance of x87 instructions has also slipped pretty
> badly in recent processors (whereas SSE has gotten relatively faster),
> so if performance matters, it is often better to use SSE at this point.

I actually measured this, which I doubt you did, and I can't agree with that at all. A new Mac has the fastest x87 implementation that was ever available. It is _slightly_ slower than double precision, but not much. They still do the stupid thing of using 16 bytes for an extended precision number, but there is actually no penalty whatsoever for storing extended precision with 10 bytes per number (2 byte alignment).

[toc] | [prev] | [next] | [standalone]

#59817

On 4/8/2015 1:58 AM, christian.bau@cbau.wanadoo.co.uk wrote:
> On Monday, April 6, 2015 at 1:30:56 AM UTC+1, BGB wrote:
>> a lot of these instructions can easily end up taking *hundreds* of CPU
>> cycles on recent processors.
>>
>> in general, the performance of x87 instructions has also slipped pretty
>> badly in recent processors (whereas SSE has gotten relatively faster),
>> so if performance matters, it is often better to use SSE at this point.
>
> I actually measured this, which I doubt you did, and I can't agree with that at all. A new Mac has the fastest x87 implementation that was ever available. It is _slightly_ slower than double precision, but not much. They still do the stupid thing of using 16 bytes for an extended precision number, but there is actually no penalty whatsoever for storing extended precision with 10 bytes per number (2 byte alignment).
>

could depend on the CPU in use.

most of my stuff at present is relative to an AMD K-10 (what I am 
using), and I was also including the AMD lines in consideration (IIRC, I 
had also looked at the Bulldozer and Piledriver charts and similar), and 
was noted mostly by looking at instruction timing charts for various 
processors.

I was also talking mostly about fsin and ftan and friends with the 
"hundreds of clock-cycles" comment, basic operations tend to be a little 
faster.

[toc] | [prev] | [next] | [standalone]

#59671

On Mon, 06 Apr 2015 01:30:29 +0200
jacobnavia <jacob@jacob.remcomp.fr> wrote:

> Le 05/04/2015 17:35, Melzzzzz a écrit :
> > On Sun, 05 Apr 2015 17:17:42 +0200
> > Noob <root@127.0.0.1> wrote:
> >
> >>
> >> And x87 is obsolete.
> >>
> >
> > Who said that?
> >
> lcc-win was generating a fsin instruction to calculate the sin(x)
> using the x87
> 
> I was completely ASTONISHED that gcc was much faster. They had an 
> optimized sin routine in SSE and their routine was faster than a
> SINGLE FPU instruction...
> 
> Intel hasn't upgraded the x87 since at least 10-15 years...
> 
> I still generate fsin though...

I have AVX/AVX2 routines to calculate sin/cos/tan in parallel and it is
twice as fast as gcc's and x87. for *single* calculation of 4 doubles ;)
I have posted ti here.
It is verabtim translation of what cephes library does, I hope someone 
find it useful :

[bmaxa@maxa-pc tasks]$ ./fptanmain 
-0.782455544155212 x87 tangent time 0.373150
-0.782455544155212 x87 tangent time 0.378290
-0.782455544155212 clib tan time 0.328371
-0.782455544155212 cephes tan time 0.354883
-0.782455544155212 tan_pd time 0.202565
0.616233456829857 x87 sine time 0.304618
0.616233456829857 clib sin time 0.271159
0.616233456829857 cephes sin time 0.308971
0.616233456829857 sin_pd time 0.155133
-0.787563538188206 x87 cosine time 0.304308
-0.787563538188206 clib cos time 0.281714
-0.787563538188206 cephes cos time 0.313464
-0.787563538188206 cos_pd time 0.234667
0.616233456829857 -0.787563538188206 x87 sincos time 0.354192
0.616233456829857 -0.787563538188206 clib sincos time 0.553157
0.616233456829857 -0.787563538188206 sincos_pd time 0.184800

source:

[bmaxa@maxa-pc tasks]$ cat fptan.asm
format elf64
define AVX2 1

macro polevl p1,p2,p3 {
	local .L0
	; %1 = ymm value,%2 = addr coef array , %3 = N
	mov rbx,p2
	lea rcx,[rbx+8*p3]
	vbroadcastsd ymm15,[rbx]
.L0:
	add rbx,8
if AVX2
	vbroadcastsd ymm14,[rbx]
	vfmadd213pd ymm15,p1,ymm14
else
	vmulpd ymm15,ymm15,p1
	vbroadcastsd ymm14,[rbx]
	vaddpd ymm15,ymm15,ymm14
end if
	cmp rbx,rcx
	jl .L0
}

macro p1evl p1,p2,p3 {
	local .L0
	; %1 = ymm value,%2 = addr coef array , %3 = N
	mov rbx,p2
	lea rcx,[rbx+8*(p3-1)]
	vbroadcastsd ymm15,[rbx]
	vaddpd ymm15,ymm15,p1
.L0:
	add rbx,8
if AVX2
	vbroadcastsd ymm14,[rbx]
	vfmadd213pd ymm15,p1,ymm14
else
	vmulpd ymm15,ymm15,p1
	vbroadcastsd ymm14,[rbx]
	vaddpd ymm15,ymm15,ymm14
end if
	cmp rbx,rcx
	jl .L0
}

section '.text' executable

public tangent
public sine
public cosine
public sin_pd
public cos_pd
public tan_pd
public x87sincos
public sincos_pd

tangent:
	sub rsp,8
	vmovsd [rsp],xmm0
	fld qword[rsp]
	fptan
	fstp st0
	fstp qword[rsp]
	vmovsd xmm0,[rsp]
	add rsp,8
	ret

sine:
	sub rsp,8
	vmovsd [rsp],xmm0
	fld qword[rsp]
	fsin
	fstp qword[rsp]
	vmovsd xmm0,[rsp]
	add rsp,8
	ret
cosine:
	sub rsp,8
	vmovsd [rsp],xmm0
	fld qword[rsp]
	fcos
	fstp qword[rsp]
	vmovsd xmm0,[rsp]
	add rsp,8
	ret
x87sincos:
	sub rsp,8
	vmovsd [rsp],xmm0
	fld qword[rsp]
	fsincos
	fstp qword[rsi]
	fstp qword[rdi]
	add rsp,8
	ret
; ymm0 -> x
sin_pd:
	push rbx
	vmovapd ymm1,ymm0
	vmovapd ymm2,[sign_mask]
	vandnpd ymm0,ymm2,ymm0 ; make positive x
	vandpd ymm1,ymm1,[sign_mask] ; save sign bit
	
	vbroadcastsd ymm2,[O4PI]
	vmulpd ymm3,ymm0,ymm2 ; 
	vroundpd ymm3,ymm3,3 ; truncate y

	vmulpd ymm2,ymm3,[OD16]
	vroundpd ymm2,ymm2,3
	
;	vmulpd ymm2,ymm2,[S16]
;	vsubpd ymm2,ymm3,ymm2

	vfnmadd132pd ymm2,ymm3,[S16]
	
	vcvttpd2dq xmm2,ymm2 ; j

	vpand xmm4,xmm2,[mask_1]
	vpaddd xmm2,xmm2,xmm4 ; j += 1
	vcvtdq2pd ymm4,xmm4
	vaddpd ymm3,ymm3,ymm4 ; y += 1.0
	
	vpand xmm4,xmm2,[mask_4]
	vpslld xmm4,xmm4,29 ; move mask to highest position
if AVX2 ; just example, too lazy to repeat for other functions ;)
	vpmovzxdq ymm4,xmm4
	vpsllq ymm4,ymm4,32
else
	vpmovzxdq xmm5,xmm4
	vpsllq xmm5,xmm5,32
	vpsrldq xmm4,xmm4,8
	vpmovzxdq xmm6,xmm4
	vpsllq xmm6,xmm6,32
	vmovapd xmm4,xmm5
	vinsertf128 ymm4,ymm4,xmm6,1
end if
	vxorpd ymm1,ymm1,ymm4 ; invert sign

	vpand xmm4,xmm2,[mask_3]
	vpcmpeqd xmm4,xmm4,[mask_0] 
if AVX2
	vpmovsxdq ymm4,xmm4
else
	vpmovsxdq xmm5,xmm4
	vpsrldq xmm4,xmm4,8
	vpmovsxdq xmm6,xmm4
	vmovapd xmm4,xmm5
	vinsertf128 ymm4,ymm4,xmm6,1 ; selection mask 
end if

; Extended precision modular arithmetic	
;	vmulpd ymm5,ymm3,[DP1]
;	vmulpd ymm6,ymm3,[DP2]
;	vmulpd ymm7,ymm3,[DP3]
;	vsubpd ymm0,ymm0,ymm5
;	vsubpd ymm0,ymm0,ymm6
;	vsubpd ymm0,ymm0,ymm7

	vfnmadd231pd ymm0,ymm3,[DP1]
	vfnmadd231pd ymm0,ymm3,[DP2]
	vfnmadd231pd ymm0,ymm3,[DP3]

	vmulpd ymm5,ymm0,ymm0 ; x^2

	; first	
	polevl ymm5,sincof,5
	vmulpd ymm15,ymm15,ymm5
;	vmulpd ymm15,ymm15,ymm0
;	vaddpd ymm6,ymm15,ymm0 ; y1
	
	vfmadd132pd ymm15,ymm0,ymm0
	vmovapd ymm6,ymm15

	; second
	polevl ymm5,coscof,5
	vmulpd ymm15,ymm15,ymm5
	vmulpd ymm15,ymm15,ymm5
;	vmulpd ymm7,ymm5,[OD2]
;	vsubpd ymm7,ymm15,ymm7

	vfnmadd231pd ymm15,ymm5,[OD2]
	vmovapd ymm7,ymm15

	vaddpd ymm7,ymm7,[one]; y2

	; combine
	vandpd ymm6,ymm4,ymm6
	vandnpd ymm7,ymm4,ymm7
	vaddpd ymm0,ymm6,ymm7

	vxorpd ymm0,ymm0,ymm1
	pop rbx
	ret
; ymm0 -> x
cos_pd:
	push rbx
	vmovapd ymm1,ymm0
	vmovapd ymm2,[sign_mask]
	vandnpd ymm0,ymm2,ymm0 ; make positive x
	vandpd ymm1,ymm1,[sign_mask] ; save sign bit
	
	vbroadcastsd ymm2,[O4PI]
	vmulpd ymm3,ymm0,ymm2 ; 
	vroundpd ymm3,ymm3,3 ; truncate y

	vmulpd ymm2,ymm3,[OD16]
	vroundpd ymm2,ymm2,3
	vmulpd ymm2,ymm2,[S16]
	vsubpd ymm2,ymm3,ymm2
	vcvttpd2dq xmm2,ymm2 ; j

	vpand xmm4,xmm2,[mask_1]
	vpaddd xmm2,xmm2,xmm4 ; j += 1
	vcvtdq2pd ymm4,xmm4
	vaddpd ymm3,ymm3,ymm4 ; y += 1.0
	
	vpand xmm4,xmm2,[mask_4]
	vpslld xmm4,xmm4,29 ; move mask to highest position
	vpmovzxdq xmm5,xmm4
	vpsllq xmm5,xmm5,32
	vpsrldq xmm4,xmm4,8
	vpmovzxdq xmm6,xmm4
	vpsllq xmm6,xmm6,32
	vmovapd xmm4,xmm5
	vinsertf128 ymm4,ymm4,xmm6,1
	vxorpd ymm1,ymm1,ymm4 ; invert sign

	vpand xmm4,xmm2,[mask_3]
	vpcmpeqd xmm4,xmm4,[mask_0] 
	vpmovsxdq xmm5,xmm4
	vpsrldq xmm4,xmm4,8
	vpmovsxdq xmm6,xmm4
	vmovapd xmm4,xmm5
	vinsertf128 ymm4,ymm4,xmm6,1 ; selection mask 

	; Extended precision modular arithmetic	
	vmulpd ymm5,ymm3,[DP1]
	vmulpd ymm6,ymm3,[DP2]
	vmulpd ymm7,ymm3,[DP3]
	vsubpd ymm0,ymm0,ymm5
	vsubpd ymm0,ymm0,ymm6
	vsubpd ymm0,ymm0,ymm7

	vmulpd ymm5,ymm0,ymm0 ; x^2

	; first	
	polevl ymm5,sincof,5
	vmulpd ymm15,ymm15,ymm5
	vmulpd ymm15,ymm15,ymm0
	vaddpd ymm6,ymm15,ymm0 ; y1
	
	; second
	polevl ymm5,coscof,5
	vmulpd ymm15,ymm15,ymm5
	vmulpd ymm15,ymm15,ymm5
	vmulpd ymm7,ymm5,[OD2]
	vsubpd ymm7,ymm15,ymm7
	vaddpd ymm7,ymm7,[one]; y2

	; combine
	vandnpd ymm6,ymm4,ymm6
	vandpd ymm7,ymm4,ymm7
	vaddpd ymm0,ymm6,ymm7

	vxorpd ymm0,ymm0,ymm1
	pop rbx
	ret
	
; ymm0 -> x
sincos_pd:
	push rbx
	vmovapd ymm1,ymm0
	vmovapd ymm2,[sign_mask]
	vandnpd ymm0,ymm2,ymm0 ; make positive x
	vandpd ymm1,ymm1,[sign_mask] ; save sign bit
	
	vbroadcastsd ymm2,[O4PI]
	vmulpd ymm3,ymm0,ymm2 ; 
	vroundpd ymm3,ymm3,3 ; truncate y

	vmulpd ymm2,ymm3,[OD16]
	vroundpd ymm2,ymm2,3
	vmulpd ymm2,ymm2,[S16]
	vsubpd ymm2,ymm3,ymm2
	vcvttpd2dq xmm2,ymm2 ; j

	vpand xmm4,xmm2,[mask_1]
	vpaddd xmm2,xmm2,xmm4 ; j += 1
	vcvtdq2pd ymm4,xmm4
	vaddpd ymm3,ymm3,ymm4 ; y += 1.0
	
	vpand xmm4,xmm2,[mask_4]
	vpslld xmm4,xmm4,29 ; move mask to highest position
	vpmovzxdq xmm5,xmm4
	vpsllq xmm5,xmm5,32
	vpsrldq xmm4,xmm4,8
	vpmovzxdq xmm6,xmm4
	vpsllq xmm6,xmm6,32
	vmovapd xmm4,xmm5
	vinsertf128 ymm4,ymm4,xmm6,1
	vxorpd ymm1,ymm1,ymm4 ; invert sign

	vpand xmm4,xmm2,[mask_3]
	vpcmpeqd xmm4,xmm4,[mask_0] 
	vpmovsxdq xmm5,xmm4
	vpsrldq xmm4,xmm4,8
	vpmovsxdq xmm6,xmm4
	vmovapd xmm4,xmm5
	vinsertf128 ymm4,ymm4,xmm6,1 ; selection mask 

	; Extended precision modular arithmetic	
	vmulpd ymm5,ymm3,[DP1]
	vmulpd ymm6,ymm3,[DP2]
	vmulpd ymm7,ymm3,[DP3]
	vsubpd ymm0,ymm0,ymm5
	vsubpd ymm0,ymm0,ymm6
	vsubpd ymm0,ymm0,ymm7

	vmulpd ymm5,ymm0,ymm0 ; x^2

	; first	
	polevl ymm5,sincof,5
	vmulpd ymm15,ymm15,ymm5
	vmulpd ymm15,ymm15,ymm0
	vaddpd ymm6,ymm15,ymm0 ; y1
	
	; second
	polevl ymm5,coscof,5
	vmulpd ymm15,ymm15,ymm5
	vmulpd ymm15,ymm15,ymm5
	vmulpd ymm7,ymm5,[OD2]
	vsubpd ymm7,ymm15,ymm7
	vaddpd ymm7,ymm7,[one]; y2

	; combine sin
	vandpd ymm8,ymm4,ymm6
	vandnpd ymm9,ymm4,ymm7
	vaddpd ymm0,ymm8,ymm9

	vxorpd ymm0,ymm0,ymm1
	vmovupd [rdi],ymm0

	; combine cos
	vandnpd ymm6,ymm4,ymm6
	vandpd ymm7,ymm4,ymm7
	vaddpd ymm0,ymm6,ymm7

	vxorpd ymm0,ymm0,ymm1
	vmovupd [rsi],ymm0
	
	pop rbx
	ret
tan_pd:
	push rbx
	vmovapd ymm1,ymm0
	vmovapd ymm2,[sign_mask]
	vandnpd ymm0,ymm2,ymm0 ; make positive x
	vandpd ymm1,ymm1,[sign_mask] ; save sign bit
	
	vbroadcastsd ymm2,[O4PI]
	vmulpd ymm3,ymm0,ymm2 ; 
	vroundpd ymm3,ymm3,3 ; truncate y

	vmulpd ymm2,ymm3,[OD16]
	vroundpd ymm2,ymm2,3
	vmulpd ymm2,ymm2,[S16]
	vsubpd ymm2,ymm3,ymm2
	vcvttpd2dq xmm2,ymm2 ; j

	vpand xmm4,xmm2,[mask_1]
	vpaddd xmm2,xmm2,xmm4 ; j += 1
	vcvtdq2pd ymm4,xmm4
	vaddpd ymm3,ymm3,ymm4 ; y += 1.0
	
	vpand xmm4,xmm2,[mask_2]
	vpcmpeqd xmm4,xmm4,[mask_0] 
	vpmovsxdq xmm5,xmm4
	vpsrldq xmm4,xmm4,8
	vpmovsxdq xmm6,xmm4
	vmovapd xmm4,xmm5
	vinsertf128 ymm4,ymm4,xmm6,1 ; selection mask 2

	; Extended precision modular arithmetic	
	vmulpd ymm5,ymm3,[DP1]
	vmulpd ymm6,ymm3,[DP2]
	vmulpd ymm7,ymm3,[DP3]
	vsubpd ymm0,ymm0,ymm5
	vsubpd ymm0,ymm0,ymm6
	vsubpd ymm0,ymm0,ymm7

	vmulpd ymm5,ymm0,ymm0 ; x^2

	vcmpnlepd ymm6,ymm5,[prec] ; selection mask 1
	
	;calculate polynom
	polevl ymm5,P,2
	vmovapd ymm13,ymm15
	p1evl ymm5,Q,4
	vdivpd ymm13,ymm13,ymm15
	vmulpd ymm13,ymm13,ymm5
	vmulpd ymm13,ymm13,ymm0
	vaddpd ymm13,ymm13,ymm0
	
	vandpd ymm13,ymm6,ymm13
	vandnpd ymm0,ymm6,ymm0 ; select according to mask 1
	vaddpd ymm0,ymm13,ymm0
	
	vmovapd ymm6,[mone]
	vdivpd ymm7,ymm6,ymm0
	
	vandpd ymm0,ymm4,ymm0
	vandnpd ymm7,ymm4,ymm7 ; select according to mask 2
	vaddpd ymm0,ymm0,ymm7
	
	vxorpd ymm0,ymm0,ymm1 ; invert sign
	pop rbx
	ret

section '.data' writeable align 32
sincof dq \
	1.58962301576546568060E-10,\
	-2.50507477628578072866E-8,\
	2.75573136213857245213E-6,\
	-1.98412698295895385996E-4,\
	8.33333333332211858878E-3,\
	-1.66666666666666307295E-1
coscof dq \
	-1.13585365213876817300E-11,\
	2.08757008419747316778E-9,\
	-2.75573141792967388112E-7,\
	2.48015872888517045348E-5,\
	-1.38888888888730564116E-3,\
	4.16666666666665929218E-2
P dq \
-1.30936939181383777646E4, \
 1.15351664838587416140E6, \
 -1.79565251976484877988E7 
Q dq \
 1.36812963470692954678E4, \
 -1.32089234440210967447E6,\
  2.50083801823357915839E7,\
  -5.38695755929454629881E7 
O4PI dq 1.273239544735162
align 32
DP1: times 4 dq   7.85398125648498535156E-1;
DP2: times 4 dq   3.77489470793079817668E-8;
DP3: times 4 dq   2.69515142907905952645E-15;
sign_mask: times 4 dq 0x8000000000000000
prec: times 4 dq 1.0e-14
one: times 4 dq 1.0
mone: times 4 dq -1.0
OD16: times 4 dq 0.0625
S16: times 4 dq 16.0
OD2: times 4 dq 0.5
mask_0: times 4 dd 0
mask_1: times 4 dd 1
mask_2: times 4 dd 2
mask_3: times 4 dd 3
mask_4: times 4 dd 4

[toc] | [prev] | [next] | [standalone]

#59732

On 06/04/15 01:30, jacobnavia wrote:
> Le 05/04/2015 17:35, Melzzzzz a écrit :
>> On Sun, 05 Apr 2015 17:17:42 +0200
>> Noob <root@127.0.0.1> wrote:
>>
>>>
>>> And x87 is obsolete.
>>>
>>
>> Who said that?
>>
> lcc-win was generating a fsin instruction to calculate the sin(x) using
> the x87
> 
> I was completely ASTONISHED that gcc was much faster. They had an
> optimized sin routine in SSE and their routine was faster than a SINGLE
> FPU instruction...
> 
> Intel hasn't upgraded the x87 since at least 10-15 years...
> 
> I still generate fsin though...

It's not /that/ surprising - doing complex functions in
hardware/microcode means finding a good balance between die area and
speed.  Since much of that die area is only used on the complex
functions, it is hard to justify its use - it is better to use the same
space to make common operations run faster.  The same thing applies to
the development of the hardware - increasing the speed of a hardware
fsin takes steadily more development effort for less and less gain, and
the effort only benefits fsin (and related functions).

So there comes a point where you realise it is not worth the cost (in
development or die space) to make hardware fsin any better - you leave
it in for compatibility with older code, and concentrate on making the
rest of the chip run faster.

On many architectures (or implementations of architectures),
instructions like fsin have been dropped completely - trying to execute
them makes the processor take a "floating point assist" exception, with
the expectation that the operating system or other library code will
emulate the instruction.  The same trick is often used for handling
NaN's, sub-normals, and other weird floating point values - keep the
hardware small and fast for common cases, and let software handle the
oddities.  Of course, such emulation is going to be slower than using a
decent library routine directly, but it allows compatibility for older
software.

On later m68k devices, it was discovered that software loops could do
integer division faster than the hardware integer division instructions
- IIRC, the later Coldfire architecture didn't bother to implement
hardware integer division at all.

[toc] | [prev] | [next] | [standalone]

#59765

On 4/7/2015 3:27 AM, David Brown wrote:
> On 06/04/15 01:30, jacobnavia wrote:
>> Le 05/04/2015 17:35, Melzzzzz a écrit :
>>> On Sun, 05 Apr 2015 17:17:42 +0200
>>> Noob <root@127.0.0.1> wrote:
>>>

> On later m68k devices, it was discovered that software loops could do
> integer division faster than the hardware integer division instructions
> - IIRC, the later Coldfire architecture didn't bother to implement
> hardware integer division at all.
>

this is also sort of the case with the AMD K-10 processors, which have 
pretty much notoriously slow integer division.


a trick to speed up integer division is to have a function which checks 
the value-ranges, using a division table for small cases, fixed-point 
math and a lookup table for some other cases, and falling back to a 
generic division function for larger cases.

another trick (usable, but still kind of expensive), was to cast both 
values to double, use a floating-point divide, and cast the result back 
to an integer.

people have noted that these tricks tend to be slower on Intel chips 
though, and later AMD chips fixed the slow hardware division issue.

[toc] | [prev] | [next] | [standalone]

#59789

On Monday, April 6, 2015 at 12:30:39 AM UTC+1, jacobnavia wrote:

> lcc-win was generating a fsin instruction to calculate the sin(x) using 
> the x87
> 
> I was completely ASTONISHED that gcc was much faster. They had an 
> optimized sin routine in SSE and their routine was faster than a SINGLE 
> FPU instruction...

Motorola removed sin, cos, ln etc from their 68040 coprocessor in the mid 90's, because they figured out they could do it faster in software using basic arithmetic functions. 

[toc] | [prev] | [next] | [standalone]

#59627

On 4/5/2015 10:17 AM, Noob wrote:
> On 05/04/2015 15:50, Weng Tianxiang wrote:
>
>> Does each core of 8-core Intel processor have an independent floating X87 unit?
>
> comp.lang.c discusses the C programming language. Your question
> is waaay off-topic. The comp.arch newsgroup might help you.
>
> This in-depth review answers your question:
> http://www.realworldtech.com/haswell-cpu/
>
> And x87 is obsolete.
>

FWIW though, typically normal apps only use floating point rarely 
(primarily or integer-only code is significantly more common), and many 
newer apps assume using SSE for all their floating-point stuff (as 
pretty much any processor made in the past decade or so supports SSE2 or 
better).

so, there isn't really much need for each core to have a dedicated x87 unit.


it is possible that if 16 and 32-bit code went away, the x87 FPU could 
possibly also go away along with it (as the 64-bit ABIs generally 
disallow use of x87, setting SSE2 as the minimum).

though this and a few other things are a PITA for anyone wanting to do a 
non-infringing x86 implementation (and use an ISA much newer than a 486 
with a few Pentium-1 features, or use non-standard ISA extensions).

[toc] | [prev] | [next] | [standalone]

#59628

On Sun, 05 Apr 2015 11:04:53 -0500
BGB <cr88192@hotmail.com> wrote:

> On 4/5/2015 10:17 AM, Noob wrote:
> > On 05/04/2015 15:50, Weng Tianxiang wrote:
> >
> >> Does each core of 8-core Intel processor have an independent
> >> floating X87 unit?
> >
> > comp.lang.c discusses the C programming language. Your question
> > is waaay off-topic. The comp.arch newsgroup might help you.
> >
> > This in-depth review answers your question:
> > http://www.realworldtech.com/haswell-cpu/
> >
> > And x87 is obsolete.
> >
> 
> FWIW though, typically normal apps only use floating point rarely 
> (primarily or integer-only code is significantly more common), and
> many newer apps assume using SSE for all their floating-point stuff
> (as pretty much any processor made in the past decade or so supports
> SSE2 or better).
> 
> so, there isn't really much need for each core to have a dedicated
> x87 unit.
> 
> 
> it is possible that if 16 and 32-bit code went away, the x87 FPU
> could possibly also go away along with it (as the 64-bit ABIs
> generally disallow use of x87, setting SSE2 as the minimum).

Since when?

[toc] | [prev] | [next] | [standalone]

#59632

On 4/5/2015 11:20 AM, Melzzzzz wrote:
> On Sun, 05 Apr 2015 11:04:53 -0500
> BGB <cr88192@hotmail.com> wrote:
>
>> On 4/5/2015 10:17 AM, Noob wrote:
>>> On 05/04/2015 15:50, Weng Tianxiang wrote:
>>>
>>>> Does each core of 8-core Intel processor have an independent
>>>> floating X87 unit?
>>>
>>> comp.lang.c discusses the C programming language. Your question
>>> is waaay off-topic. The comp.arch newsgroup might help you.
>>>
>>> This in-depth review answers your question:
>>> http://www.realworldtech.com/haswell-cpu/
>>>
>>> And x87 is obsolete.
>>>
>>
>> FWIW though, typically normal apps only use floating point rarely
>> (primarily or integer-only code is significantly more common), and
>> many newer apps assume using SSE for all their floating-point stuff
>> (as pretty much any processor made in the past decade or so supports
>> SSE2 or better).
>>
>> so, there isn't really much need for each core to have a dedicated
>> x87 unit.
>>
>>
>> it is possible that if 16 and 32-bit code went away, the x87 FPU
>> could possibly also go away along with it (as the 64-bit ABIs
>> generally disallow use of x87, setting SSE2 as the minimum).
>
> Since when?
>

AFAIK, this was an interpretation at least early on for the Win64 ABI, 
as-in, you are generally not supposed to use x87.

the ABI also treats it as volatile, and is not necessarily preserved 
across context switches (though IME is preserved at least for Ring-3 
WoW64 processes).


however, SysV/AMD64 still specifies x87 as existing, and x87 state is 
preserved, though SSE is primarily used for passing/returning values.

in both cases though, x87 instructions still work though, and it would 
likely still pose a problem for some existing code if x87 support were 
removed.


but, by the time someone got around to making a 64-bit only CPU, it is 
likely x87 would be mostly dead and gone by that point, and any code 
depending on the x87 FPU would be treated about like how 16-bit 
applications were treated in the move to 64-bit Windows.

[toc] | [prev] | [next] | [standalone]

#59657

BGB <cr88192@hotmail.com> wrote:

(snip, someone wrote)
>> And x87 is obsolete.
 
> FWIW though, typically normal apps only use floating point rarely 
> (primarily or integer-only code is significantly more common), and many 
> newer apps assume using SSE for all their floating-point stuff (as 
> pretty much any processor made in the past decade or so supports SSE2 or 
> better).

Maybe for your normal apps, but in scientific computing, where floating
point originated, it is still very common. 
 
> so, there isn't really much need for each core to have a dedicated x87 unit.

Well, each core would need it own x87 registers. I suppose you could
arrange one floating point processor even in that case.

-- glen

[toc] | [prev] | [next] | [standalone]

#59663

On Sunday, April 5, 2015 at 9:29:05 PM UTC+1, glen herrmannsfeldt wrote:
> BGB <cr88192@hotmail.com> wrote:
> 
> > FWIW though, typically normal apps only use floating point rarely 
> > (primarily or integer-only code is significantly more common), and many 
> > newer apps assume using SSE for all their floating-point stuff (as 
> > pretty much any processor made in the past decade or so supports SSE2 or 
> > better).
> 
> Maybe for your normal apps, but in scientific computing, where floating
> point originated, it is still very common. 
>  
It just depends what you're doing. It's probably fair to say that the
typical business app on a modern desktop does absolutely trivial
processing as its core work, maybe calculating tax for 100 employees
(so maybe a thousand flops, or about a millionth of a second of the processor's time). But it wraps that up in lots of UI code, so it
might spend several seconds of processor time writing pixels to a
screen buffer to indicate that the "expenses signed off by accountant"
box has been checked.

But a game typically makes quite heavy use of 3D calculations,
usually done in floating point. As do Bezier-curve based 2D
drawing apps, or 3D CAD / virtual reality systems. Then scientific
apps, as mentioned, might do huge numbers of flops, or they 
might do none at all, and often they run for days at a time.

[toc] | [prev] | [next] | [standalone]

#59666

W dniu niedziela, 5 kwietnia 2015 23:47:03 UTC+2 użytkownik Malcolm McLean napisał:
> On Sunday, April 5, 2015 at 9:29:05 PM UTC+1, glen herrmannsfeldt wrote:
> > BGB <cr88192@hotmail.com> wrote:
> > 
> > > FWIW though, typically normal apps only use floating point rarely 
> > > (primarily or integer-only code is significantly more common), and many 
> > > newer apps assume using SSE for all their floating-point stuff (as 
> > > pretty much any processor made in the past decade or so supports SSE2 or 
> > > better).
> > 
> > Maybe for your normal apps, but in scientific computing, where floating
> > point originated, it is still very common. 
> >  
> It just depends what you're doing. It's probably fair to say that the
> typical business app on a modern desktop does absolutely trivial
> processing as its core work, maybe calculating tax for 100 employees
> (so maybe a thousand flops, or about a millionth of a second of the processor's time). But it wraps that up in lots of UI code, so it
> might spend several seconds of processor time writing pixels to a
> screen buffer to indicate that the "expenses signed off by accountant"
> box has been checked.
> 
> But a game typically makes quite heavy use of 3D calculations,
> usually done in floating point. As do Bezier-curve based 2D
> drawing apps, or 3D CAD / virtual reality systems. Then scientific
> apps, as mentioned, might do huge numbers of flops, or they 
> might do none at all, and often they run for days at a time.

well its like natural numbers and real numbers
(both are common in real life)

some could say that normall app is not doing
mayby any numers not only real bat also natural.. it may do for example text 
processing and simple 'input distatching'
- many elements in code are denoted by numbers but in abstract way those numnbers are miore laike handles not real natural numbers here..
programing without numbers is probably at all quite possible

[toc] | [prev] | [next] | [standalone]

#59652

Noob <root@127.0.0.1> writes:
> On 05/04/2015 15:50, Weng Tianxiang wrote:
>> Does each core of 8-core Intel processor have an independent floating
>> X87 unit?
>
> comp.lang.c discusses the C programming language. Your question
> is waaay off-topic. The comp.arch newsgroup might help you.
>
> This in-depth review answers your question:
> http://www.realworldtech.com/haswell-cpu/

Good answer, but ...

> And x87 is obsolete.

... unfortunately, this triggered a lengthy off-topic thread.

If you're going to respond to an off-topic question, I suggest pointing
to an appropriate forum and leaving it at that.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#59646

Weng Tianxiang wrote:
> Hi, 
> Does each core of 8-core Intel processor has an independent floating X87 unit? 
> 
> Here are some texts from Intel latest datasheet: 
> 
> Intel(R) Core(tm) i7 Processor Family for LGA2011-v3 Socket 
> Datasheet - Volume 1 of 2 
> 
> Processor Feature Details 
> *Up to 8 execution cores 
> *Each core supports two threads (Intel(R) Hyper-Threading Technology) 
> *32 KB instruction and 32 KB data first-level cache (L1) for each core 
> *256 KB shared instruction/data mid-level (L2) cache for each core 
> *Up to 15 MB last level cache (LLC): up to 2.5 MB per core instruction/data last level cache (LLC), shared among all cores. 
> 
> 5.2 X87 FPU INSTRUCTIONS 
> The x87 FPU instructions are executed by the processor's x87 FPU. These instructions operate on floating-point, integer, and binary-coded decimal (BCD) operands. For more detail on x87 FPU instructions, see Chapter 8, "Programming with the x87 FPU."
> 
> These instructions are divided into the following subgroups: data transfer, load constants, and FPU control instructions. 
> 
> From above text I have a feeling that all 8 execution cores share the same X87 FPU unit. 
> 
> Am I right or not? 
> 
> Is there anyone who has real experiences with X87 FPU unit? 
> 
> Thank you. 
> 
> Weng 

Take a 4C 8T (hyperthreaded) processor, like this one.

http://ark.intel.com/products/80807/Intel-Core-i7-4790K-Processor-8M-Cache-up-to-4_40-GHz

This would be a drawing of the processor. I do not know the
details of the FPU section, whether there are one or two
units, how fast they can retire instructions. So this is only
a rough approximation.

Logical  Logical  Logical Logical  Logical Logical  Logical Logical
Core 0   Core 1   Core 2  Core 3   Core 4  Core 5   Core 6  Core 7
    \      /         \       /        \       /        \       /
    Physical         Physical         Physical         Physical
    Dispatch -- FPU  Dispatch -- FPU  dispatch -- FPU  Dispatch -- FPU
       |                |
    (retired        (retired          (retired        (retired
     instructions)   instructions)     instructions)   instructions)

Only enough of the architecture is shown in this diagram,
to point out that the processor *actually* only has 4 cores (not 8),
and a dedicated FPU is associated with each core. I do not
know the exact details of that FPU.

Hyperthreading is an overlay on top of that, where core state
is preserved on a stall, and the core can work on a second task
which is not stalled. Thus squeezing 10% more performance from the
four cores. In Windows, you see eight performance graphs,
but it's all a sham. You're seeing 4.4 cores of performance,
graphed in 8 graph columns.

    Paul

[toc] | [prev] | [next] | [standalone]

#59736

On 05/04/15 20:31, Paul wrote:
> Weng Tianxiang wrote:
>> Hi, Does each core of 8-core Intel processor has an independent
>> floating X87 unit?
>> Here are some texts from Intel latest datasheet:
>> Intel(R) Core(tm) i7 Processor Family for LGA2011-v3 Socket Datasheet
>> - Volume 1 of 2
>> Processor Feature Details *Up to 8 execution cores *Each core supports
>> two threads (Intel(R) Hyper-Threading Technology) *32 KB instruction
>> and 32 KB data first-level cache (L1) for each core *256 KB shared
>> instruction/data mid-level (L2) cache for each core *Up to 15 MB last
>> level cache (LLC): up to 2.5 MB per core instruction/data last level
>> cache (LLC), shared among all cores.
>> 5.2 X87 FPU INSTRUCTIONS The x87 FPU instructions are executed by the
>> processor's x87 FPU. These instructions operate on floating-point,
>> integer, and binary-coded decimal (BCD) operands. For more detail on
>> x87 FPU instructions, see Chapter 8, "Programming with the x87 FPU."
>>
>> These instructions are divided into the following subgroups: data
>> transfer, load constants, and FPU control instructions.
>> From above text I have a feeling that all 8 execution cores share the
>> same X87 FPU unit.
>> Am I right or not?
>> Is there anyone who has real experiences with X87 FPU unit?
>> Thank you.
>> Weng 
> 
> Take a 4C 8T (hyperthreaded) processor, like this one.
> 
> http://ark.intel.com/products/80807/Intel-Core-i7-4790K-Processor-8M-Cache-up-to-4_40-GHz
> 
> 
> This would be a drawing of the processor. I do not know the
> details of the FPU section, whether there are one or two
> units, how fast they can retire instructions. So this is only
> a rough approximation.
> 
> Logical  Logical  Logical Logical  Logical Logical  Logical Logical
> Core 0   Core 1   Core 2  Core 3   Core 4  Core 5   Core 6  Core 7
>    \      /         \       /        \       /        \       /
>    Physical         Physical         Physical         Physical
>    Dispatch -- FPU  Dispatch -- FPU  dispatch -- FPU  Dispatch -- FPU
>       |                |
>    (retired        (retired          (retired        (retired
>     instructions)   instructions)     instructions)   instructions)
> 
> Only enough of the architecture is shown in this diagram,
> to point out that the processor *actually* only has 4 cores (not 8),
> and a dedicated FPU is associated with each core. I do not
> know the exact details of that FPU.
> 
> Hyperthreading is an overlay on top of that, where core state
> is preserved on a stall, and the core can work on a second task
> which is not stalled. Thus squeezing 10% more performance from the
> four cores. In Windows, you see eight performance graphs,
> but it's all a sham. You're seeing 4.4 cores of performance,
> graphed in 8 graph columns.
> 

The performance gain from hyperthreading depends on the hardware
implementation of hyperthreading, the software tasks in question, and
the sophistication of the operating system.  Back when hyperthreading
was young in the x86 world (on the P4), the "logical cores" had very
little in them, and Windows was incapable of using them properly - it
viewed them as two real processors.  The result was poor scheduling and
the extra cache abuse meant that many tasks ran slower with
hyperthreading enabled.

At around the same time, hyperthreading (or SMT) was used in the big cpu
world (such as MIPS, Power, SPARC, etc.) to much greater effect - partly
because of better hardware, partly because of better OS support (which
was developed tightly together with the chips), and partly because of
more appropriate software loads (server software rather than desktop
software).  Modern "big cpu" designs usually have between 2 and 8
logical cores per physical core.

These days, the x86 hardware implementation is better, and more
efficiently combined with superscaler execution.  Linux understands SMT,
and schedules processes and threads to take advantage of them (such as
by spreading operations amongst real cores, or considering cache
contents) - and from something I read, I think one of the only
advantages of Win8 over Win7 is that it is better at scheduling on
hyperthreaded cores.  And the use of multiple threads has become more
common in software, leading to further improvements.

Testing "time make", "time make -j 4" and "time make -j 8" on a project
with 80-something C files on my i7 with 4 + 4 cores, shows that
utilising 4 cores builds a little over 3 times faster than 1 core, and
utilising 8 cores builds almost 4.5 times faster.  The hyperthreading
does not give me twice the processing power for this real-world task,
but it's around 30% faster.  If I were to cut out the single thread
bottlenecks (like linking, or the makefile processing), it would be even
higher.

[toc] | [prev] | [next] | [standalone]

#59675

On Sun, 5 Apr 2015 06:50:49 -0700 (PDT), Weng Tianxiang
<wtxwtx@gmail.com> wrote:

>Hi, 
>Does each core of 8-core Intel processor has an independent floating X87 unit? 
>
>Here are some texts from Intel latest datasheet: 
>
>Intel(R) Core(tm) i7 Processor Family for LGA2011-v3 Socket 
>Datasheet - Volume 1 of 2 
>
>Processor Feature Details 
>*Up to 8 execution cores 
>*Each core supports two threads (Intel(R) Hyper-Threading Technology) 
>*32 KB instruction and 32 KB data first-level cache (L1) for each core 
>*256 KB shared instruction/data mid-level (L2) cache for each core 
>*Up to 15 MB last level cache (LLC): up to 2.5 MB per core instruction/data last level cache (LLC), shared among all cores. 
>
>5.2 X87 FPU INSTRUCTIONS 
>The x87 FPU instructions are executed by the processor's x87 FPU. These instructions operate on floating-point, integer, and binary-coded decimal (BCD) operands. For more detail on x87 FPU instructions, see Chapter 8, "Programming with the x87 FPU."
>
>These instructions are divided into the following subgroups: data transfer, load constants, and FPU control instructions. 
>
>From above text I have a feeling that all 8 execution cores share the same X87 FPU unit. 
>
>Am I right or not? 
>
>Is there anyone who has real experiences with X87 FPU unit? 



All current Intel x86s have the FPU on each core.  Some recent AMD
processors have had an FPU shared between two cores.

[toc] | [prev] | [next] | [standalone]

#59679

On Sunday, April 5, 2015 at 8:34:32 PM UTC-7, robert...@yahoo.com wrote:
> On Sun, 5 Apr 2015 06:50:49 -0700 (PDT), Weng Tianxiang
> <wtxwtx@gmail.com> wrote:
> 
> >Hi, 
> >Does each core of 8-core Intel processor has an independent floating X87 unit? 
> >
> >Here are some texts from Intel latest datasheet: 
> >
> >Intel(R) Core(tm) i7 Processor Family for LGA2011-v3 Socket 
> >Datasheet - Volume 1 of 2 
> >
> >Processor Feature Details 
> >*Up to 8 execution cores 
> >*Each core supports two threads (Intel(R) Hyper-Threading Technology) 
> >*32 KB instruction and 32 KB data first-level cache (L1) for each core 
> >*256 KB shared instruction/data mid-level (L2) cache for each core 
> >*Up to 15 MB last level cache (LLC): up to 2.5 MB per core instruction/data last level cache (LLC), shared among all cores. 
> >
> >5.2 X87 FPU INSTRUCTIONS 
> >The x87 FPU instructions are executed by the processor's x87 FPU. These instructions operate on floating-point, integer, and binary-coded decimal (BCD) operands. For more detail on x87 FPU instructions, see Chapter 8, "Programming with the x87 FPU."
> >
> >These instructions are divided into the following subgroups: data transfer, load constants, and FPU control instructions. 
> >
> >From above text I have a feeling that all 8 execution cores share the same X87 FPU unit. 
> >
> >Am I right or not? 
> >
> >Is there anyone who has real experiences with X87 FPU unit? 
> 
> 
> 
> All current Intel x86s have the FPU on each core.  Some recent AMD
> processors have had an FPU shared between two cores.

Robert,
Thank you for your reply.

The following statement comes from the 5th processor document and it doesn't mention the core X87, but says the processor's x87 FPU!!!

>The x87 FPU instructions are executed by the processor's x87 FPU. 

Where do you know "All current Intel x86s have the FPU on each core"?

Weng

[toc] | [prev] | [next] | [standalone]

#59681

On Sun, 5 Apr 2015 23:39:16 -0700 (PDT), Weng Tianxiang
<wtxwtx@gmail.com> wrote:

>On Sunday, April 5, 2015 at 8:34:32 PM UTC-7, robert...@yahoo.com wrote:
>> On Sun, 5 Apr 2015 06:50:49 -0700 (PDT), Weng Tianxiang
>> <wtxwtx@gmail.com> wrote:
>> 
>> >Hi, 
>> >Does each core of 8-core Intel processor has an independent floating X87 unit? 
>> >
>> >Here are some texts from Intel latest datasheet: 
>> >
>> >Intel(R) Core(tm) i7 Processor Family for LGA2011-v3 Socket 
>> >Datasheet - Volume 1 of 2 
>> >
>> >Processor Feature Details 
>> >*Up to 8 execution cores 
>> >*Each core supports two threads (Intel(R) Hyper-Threading Technology) 
>> >*32 KB instruction and 32 KB data first-level cache (L1) for each core 
>> >*256 KB shared instruction/data mid-level (L2) cache for each core 
>> >*Up to 15 MB last level cache (LLC): up to 2.5 MB per core instruction/data last level cache (LLC), shared among all cores. 
>> >
>> >5.2 X87 FPU INSTRUCTIONS 
>> >The x87 FPU instructions are executed by the processor's x87 FPU. These instructions operate on floating-point, integer, and binary-coded decimal (BCD) operands. For more detail on x87 FPU instructions, see Chapter 8, "Programming with the x87 FPU."
>> >
>> >These instructions are divided into the following subgroups: data transfer, load constants, and FPU control instructions. 
>> >
>> >From above text I have a feeling that all 8 execution cores share the same X87 FPU unit. 
>> >
>> >Am I right or not? 
>> >
>> >Is there anyone who has real experiences with X87 FPU unit? 
>> 
>> 
>> 
>> All current Intel x86s have the FPU on each core.  Some recent AMD
>> processors have had an FPU shared between two cores.
>
>Robert,
>Thank you for your reply.
>
>The following statement comes from the 5th processor document and it doesn't mention the core X87, but says the processor's x87 FPU!!!
>
>>The x87 FPU instructions are executed by the processor's x87 FPU. 
>
>Where do you know "All current Intel x86s have the FPU on each core"?


The architectural documents specify nothing at all about the location
of the FPUs.  They describe its function, not its implementation.  For
all the architectural documents care, the CPU could be emailing a
server in Wyoming to get FPU operations performed.  They're considered
somewhat separately for historical reasons - pre-486, the FPU was
actually a separate chip, and often not included in a system (even on
486s they were often not included, but the FPU was on the processor
chip).

If you want to know how it's implemented, you need to look at some of
the implementation details reveal by Intel, often at venues like Hot
Chips, or look at one of the micro-architectural overview like this
one:

http://www.realworldtech.com/haswell-cpu/

There is, of course, nothing to prevent Intel from building a CPU
tomorrow with an FPU shared between cores (after all AMD already does
that), but latency issues and the modest size of the scalar FPU makes
it only a modest win.  In AMD's case, they shared the entire FPU (x87,
MMX, SSE, etc.) between cores.  A complication in any sort of shared
scheme is that all the cores sharing the FPU need their own set of
registers and such.

For just the x87, a bunch of what's needed for the x87 is needed
anyway for SSE support, so separating just the x87 support is really
unlikely to be worthwhile.  If Intel decided to depreciate x87
support, I suspect it would be by reducing most of the x87
instructions to microcode, which did most of the work under the hood
on the SSE hardware - wherever that hardware might be - but it still
wouldn't likely be moved out by itself).

[toc] | [prev] | [next] | [standalone]

#59688

On 4/6/2015 2:06 AM, Robert Wessel wrote:
> On Sun, 5 Apr 2015 23:39:16 -0700 (PDT), Weng Tianxiang
> <wtxwtx@gmail.com> wrote:
>
>> On Sunday, April 5, 2015 at 8:34:32 PM UTC-7, robert...@yahoo.com wrote:
>>> On Sun, 5 Apr 2015 06:50:49 -0700 (PDT), Weng Tianxiang
>>> <wtxwtx@gmail.com> wrote:
>>>
>>>> Hi,
>>>> Does each core of 8-core Intel processor has an independent floating X87 unit?
>>>>
>>>> Here are some texts from Intel latest datasheet:
>>>>
>>>> Intel(R) Core(tm) i7 Processor Family for LGA2011-v3 Socket
>>>> Datasheet - Volume 1 of 2
>>>>
>>>> Processor Feature Details
>>>> *Up to 8 execution cores
>>>> *Each core supports two threads (Intel(R) Hyper-Threading Technology)
>>>> *32 KB instruction and 32 KB data first-level cache (L1) for each core
>>>> *256 KB shared instruction/data mid-level (L2) cache for each core
>>>> *Up to 15 MB last level cache (LLC): up to 2.5 MB per core instruction/data last level cache (LLC), shared among all cores.
>>>>
>>>> 5.2 X87 FPU INSTRUCTIONS
>>>> The x87 FPU instructions are executed by the processor's x87 FPU. These instructions operate on floating-point, integer, and binary-coded decimal (BCD) operands. For more detail on x87 FPU instructions, see Chapter 8, "Programming with the x87 FPU."
>>>>
>>>> These instructions are divided into the following subgroups: data transfer, load constants, and FPU control instructions.
>>>>
>>> >From above text I have a feeling that all 8 execution cores share the same X87 FPU unit.
>>>>
>>>> Am I right or not?
>>>>
>>>> Is there anyone who has real experiences with X87 FPU unit?
>>>
>>>
>>>
>>> All current Intel x86s have the FPU on each core.  Some recent AMD
>>> processors have had an FPU shared between two cores.
>>
>> Robert,
>> Thank you for your reply.
>>
>> The following statement comes from the 5th processor document and it doesn't mention the core X87, but says the processor's x87 FPU!!!
>>
>>> The x87 FPU instructions are executed by the processor's x87 FPU.
>>
>> Where do you know "All current Intel x86s have the FPU on each core"?
>
>
> The architectural documents specify nothing at all about the location
> of the FPUs.  They describe its function, not its implementation.  For
> all the architectural documents care, the CPU could be emailing a
> server in Wyoming to get FPU operations performed.  They're considered
> somewhat separately for historical reasons - pre-486, the FPU was
> actually a separate chip, and often not included in a system (even on
> 486s they were often not included, but the FPU was on the processor
> chip).
>

IIRC, with the 486SX, the FPU was still in the processor (early on), 
just they had it disabled. with the 486DX line, it was always enabled. 
later on, the 486SX line went and apparently omitted the FPU entirely.


with the 386 and earlier, I think most people didn't have FPUs.

IIRC, the first computer I had after having an 8088, was a 386SX (it had 
the CPU soldered directly to the MOBO as a QFP-style package, and SIMMs 
in place of discrete RAM chips).

this was also back in the days where newer computers had ATA/IDE, but a 
lot of the computers around still used ST-506 drives (and most of the 
processors and other chips in PCs were still DIP based).

so, in a way, the 386 was a bridge between the older and newer styles of 
electronics, like the rise of surface-mount chips, displacing the pretty 
much entirely DIP boards that were the 8088 and 286.


> If you want to know how it's implemented, you need to look at some of
> the implementation details reveal by Intel, often at venues like Hot
> Chips, or look at one of the micro-architectural overview like this
> one:
>
> http://www.realworldtech.com/haswell-cpu/
>
> There is, of course, nothing to prevent Intel from building a CPU
> tomorrow with an FPU shared between cores (after all AMD already does
> that), but latency issues and the modest size of the scalar FPU makes
> it only a modest win.  In AMD's case, they shared the entire FPU (x87,
> MMX, SSE, etc.) between cores.  A complication in any sort of shared
> scheme is that all the cores sharing the FPU need their own set of
> registers and such.
>

I am using an AMD CPU, FWIW.


> For just the x87, a bunch of what's needed for the x87 is needed
> anyway for SSE support, so separating just the x87 support is really
> unlikely to be worthwhile.  If Intel decided to depreciate x87
> support, I suspect it would be by reducing most of the x87
> instructions to microcode, which did most of the work under the hood
> on the SSE hardware - wherever that hardware might be - but it still
> wouldn't likely be moved out by itself).
>

yeah, maybe they could fake the x87 by doing all floating-point math 
using doubles (and/or add 128 bit float support), and do all the MMX 
stuff using SSE operations.

I guess you would need some special hidden registers and similar for 
this though.

[toc] | [prev] | [next] | [standalone]

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

Back to top | Article view | comp.lang.c

csiph-web