Personal computing discussed

Moderators: renee, Flying Fox, morphine

 
morphine
TR Staff
Posts: 11600
Joined: Fri Dec 27, 2002 8:51 pm
Location: Portugal (that's next to Spain)

Re: Floating-point units in server-grade CPUs

Sun Nov 14, 2010 4:50 pm

Shining Arcanine wrote:
If you want to summarize, then let us talk about your knowledge. How many computer programs have you written? How many bug reports have you filed for other people's programs? How many patches have you produced for those bug reports?

SA, I'm a web developer (and sysadmin) with ~10 years of experience, and I cut my teeth doing assembly and C (strangely enough), with most of a CS degree.So you can count my programs on the thousands, not that it matters much. And still I am small fry and must bow to many forum members in this thread whose knowledge far exceeds mine. But that's completely secondary. The main thing is that we (as in, pretty much everyone in the thread that's not you) are not making outlandish claims based on theory alone. That's the difference right there. I don't have to prove anything to you. You're the one saying that we're all wrong (and here, "we" is everyone else in the thread, plus Intel, AMD, ARM, Motorola, etc).

Shining Arcanine wrote:
The ability to put a bunch of hardware components together and install Windows makes you a technician, not an expert.

The ability of picking up a tiny bit of theory,trying to shoehorn it into every practical situation, taking an arrogant stance and dismissing everyone's arguments with much hand-waving makes you a loudmouth politician, not a scientist.
There is a fixed amount of intelligence on the planet, and the population keeps growing :(
 
bitvector
Grand Gerbil Poohbah
Posts: 3293
Joined: Wed Jun 22, 2005 4:39 pm
Location: San Francisco, CA

Re: Floating-point units in server-grade CPUs

Sun Nov 14, 2010 4:54 pm

Shining Arcanine wrote:
If you look hard enough, it would be difficult to find a program that does not use floating point instructions. Operating systems use floating point intructions in their CPU schedulers.
No they don't. In general, operating systems specifically try to avoid use of floating point inside kernel space:
* Linus Torvalds on LKML explaining, "the rule is that you really shouldn't use FP in the kernel. ... the only 'proper' FPU user is actually the RAID checksumming MMX stuff."
* FreeBSD dev explaining why you can't use floating-point in the FreeBSD kernel
* Another Linux dev explaining why you don't use FP in a kernel

Windows has some of the same restrictions, but since it is pretty much an x86-specific OS, they do allow SSE floating point in drivers on 64-bit since the hardware all has FPUs and saves the SSE context (and, like Linux, on 32-bit if you carefully call KeSaveFloatingPointState / KeRestoreFloatingPointState around any use of FP values). But even then, I'd be surprised if their scheduler use FP. You don't really need it in a scheduler anyway. Plus, the kernel FPU emulation often doesn't work right if invoked from kernel mode, so you'd need a guaranteed hardware FPU to use floating point in the kernel anyway, limiting you from running on embedded devices that rely on OS FPU emulation (as Linus explains, "using FP in the kernel assumes that you actually _have_ an FPU, of course. The in-kernel FP emulation package is _not_ supposed to work with kernel FP instructions..").
 
Shining Arcanine
Gerbil Jedi
Topic Author
Posts: 1718
Joined: Wed Jun 11, 2003 11:30 am

Re: Floating-point units in server-grade CPUs

Sun Nov 14, 2010 6:52 pm

morphine wrote:
Shining Arcanine wrote:
If you want to summarize, then let us talk about your knowledge. How many computer programs have you written? How many bug reports have you filed for other people's programs? How many patches have you produced for those bug reports?

SA, I'm a web developer (and sysadmin) with ~10 years of experience, and I cut my teeth doing assembly and C (strangely enough), with most of a CS degree.So you can count my programs on the thousands, not that it matters much. And still I am small fry and must bow to many forum members in this thread whose knowledge far exceeds mine. But that's completely secondary. The main thing is that we (as in, pretty much everyone in the thread that's not you) are not making outlandish claims based on theory alone. That's the difference right there. I don't have to prove anything to you. You're the one saying that we're all wrong (and here, "we" is everyone else in the thread, plus Intel, AMD, ARM, Motorola, etc).

Shining Arcanine wrote:
The ability to put a bunch of hardware components together and install Windows makes you a technician, not an expert.

The ability of picking up a tiny bit of theory,trying to shoehorn it into every practical situation, taking an arrogant stance and dismissing everyone's arguments with much hand-waving makes you a loudmouth politician, not a scientist.


Intel, AMD, ARM, Motorola, etcetera all believe that single thread performance is dead as far as increases in performance are concerned and are committed to a multi-core future. Improvements in single thread performance give diminishing returns because of physics, while improvements in multiple thread performance are allowed by the laws of physics. If that were not the case, the Netburst architecture would never have failed. There is plenty of talk about creating CPUs that are capable of executing many more threads concurrently at the expense of single threaded performance and there has been some progress in doing in that. Oracle's Niagara architecture is designed according to that philosophy and AMD's Bulldozer is also a step in that direction, with peak floating point performance being halved by virtue of having half the floating point units. IBM's POWER7 series uses eDRAM to allow it to put more cores on each die, at the expense of single thread performance, which would be slightly better had conventional cache been used.

I think that this discussion is not about what the future holds, but about the acceptability of describing it. People were happy discussing some pointless thing in the present, but then I brought the future into the discussion and your worlds shattered. Anyone who suggests that things will be fundamentally different tomorrow automatically must be discredited and lambasted as being wrong. It is a mob mentality and I find such mentalities to be absurd. I will tell you that common knowledge about how things work today will not continue to be accurate in the future because fundamental changes in how things are done are needed to move forward. The sameness of having a new chip that does everything the previous chip did except with less energy and in less time will change in 10 years. The models of programming people use today are changing to accommodate that. Things have been changing for the longest time and things will continue to change in the future. Shooting the messenger when he tells you that what you had thought to be static notions of how the world works are not actually static is a remarkably backward thing to do. People in any age will shoot the messenger when told that the center of their universe is not what they thought, whether it is the earth or single thread performance in CPUs.

bitvector wrote:
Shining Arcanine wrote:
If you look hard enough, it would be difficult to find a program that does not use floating point instructions. Operating systems use floating point intructions in their CPU schedulers.
No they don't. In general, operating systems specifically try to avoid use of floating point inside kernel space:
* Linus Torvalds on LKML explaining, "the rule is that you really shouldn't use FP in the kernel. ... the only 'proper' FPU user is actually the RAID checksumming MMX stuff."
* FreeBSD dev explaining why you can't use floating-point in the FreeBSD kernel
* Another Linux dev explaining why you don't use FP in a kernel

Windows has some of the same restrictions, but since it is pretty much an x86-specific OS, they do allow SSE floating point in drivers on 64-bit since the hardware all has FPUs and saves the SSE context (and, like Linux, on 32-bit if you carefully call KeSaveFloatingPointState / KeRestoreFloatingPointState around any use of FP values). But even then, I'd be surprised if their scheduler use FP. You don't really need it in a scheduler anyway. Plus, the kernel FPU emulation often doesn't work right if invoked from kernel mode, so you'd need a guaranteed hardware FPU to use floating point in the kernel anyway, limiting you from running on embedded devices that rely on OS FPU emulation (as Linus explains, "using FP in the kernel assumes that you actually _have_ an FPU, of course. The in-kernel FP emulation package is _not_ supposed to work with kernel FP instructions..").


The BSD 4.3 kernel used floated point arithmetic in its scheduler and later versions of FreeBSD likely inherited that. I have seen snippets of the source code and you can access the scheduler's internal floating point values by executing "uptime". I do not believe any OS kernel in existence makes significant use of floating point arithmetic, but if you were to disassemble one and search the disassembly for floating point instructions, you would find them. With cases like FreeBSD and Linux, you can check the source. While I do not have the source to FreeBSD readily available, I do have the source to Linux available and it uses floating point arithemetic:

# grep -r "float" /usr/src/linux-2.6.35.8 | wc -l
2390

# grep -r "double" /usr/src/linux-2.6.35.8 | wc -l
3253


You can write a scheduler that does not use floating point arithmetic, but you would still need some sort of way of representing fractions and floating point arithmetic is convenient for that. Kernels use exponential moving averages in things like TCP/IP's RTT and various schedulers to keep track of trends. That is why if you want to compile one for a CPU that does not have a floating point unit on an ISA that normally does have them, you need to tell the compiler that so that it inlines functions that do floating point arithmetic with integer instructions in those cases. Otherwise, you get a kernel panic the moment an illegal instruction is executed in kernel code.
Disclaimer: I over-analyze everything, so try not to be offended if I over-analyze something you wrote.
 
Meadows
Grand Gerbil Poohbah
Posts: 3416
Joined: Mon Oct 08, 2007 1:10 pm
Location: Location: Location

Re: Floating-point units in server-grade CPUs

Sun Nov 14, 2010 8:49 pm

Shining Arcanine wrote:
Intel, AMD, ARM, Motorola, etcetera all believe that single thread performance is dead

Have you worked for them all already to know? Did they all fire you? :wink:
 
tfp
Grand Gerbil Poohbah
Posts: 3413
Joined: Wed Sep 24, 2003 11:09 am

Re: Floating-point units in server-grade CPUs

Sun Nov 14, 2010 9:59 pm

Shining Arcanine wrote:
I think that this discussion is not about what the future holds, but about the acceptability of describing it. People were happy discussing some pointless thing in the present, but then I brought the future into the discussion and your worlds shattered. Anyone who suggests that things will be fundamentally different tomorrow automatically must be discredited and lambasted as being wrong. It is a mob mentality and I find such mentalities to be absurd. I will tell you that common knowledge about how things work today will not continue to be accurate in the future because fundamental changes in how things are done are needed to move forward. The sameness of having a new chip that does everything the previous chip did except with less energy and in less time will change in 10 years. The models of programming people use today are changing to accommodate that. Things have been changing for the longest time and things will continue to change in the future. Shooting the messenger when he tells you that what you had thought to be static notions of how the world works are not actually static is a remarkably backward thing to do. People in any age will shoot the messenger when told that the center of their universe is not what they thought, whether it is the earth or single thread performance in CPUs.


[/Slow clap]

I am just impressed. Don't strain yourself patting yourself on the back, you might not be able to continue to give your most valuable insight on these forums.

All you do is ignore what people post, nit pick things that don't matter to look right/knowledgable, and then spout off on items you have absolutely know really experience with. Discussing things to learn because one doesn't have all of the info is great but you are unwilling or unable to listen to anything that anyone has to say. SA, you just jump around on topics hoping to avoid the actual topic in its current form which you probably redirected by your ramblings, question avoidance, and quest to be "right". If you put even some of the effort you do posting this non-sense into listening and understanding you would actually be a resource to the forum instead of just flat out silly.

Btw you probably don't mean to include Motorola with AMD/Intel (at least in the same light) they spun off the chip division years ago, that company is called Freescale or FSL when they were still publicly traded. They make embedded type processors mostly...
 
MadManOriginal
Gerbil Jedi
Posts: 1533
Joined: Wed Jan 30, 2002 7:00 pm
Location: In my head...

Re: Floating-point units in server-grade CPUs

Sun Nov 14, 2010 10:41 pm

This thread is full of epic douchebaggery.
 
bitvector
Grand Gerbil Poohbah
Posts: 3293
Joined: Wed Jun 22, 2005 4:39 pm
Location: San Francisco, CA

Re: Floating-point units in server-grade CPUs

Mon Nov 15, 2010 12:29 am

Shining Arcanine wrote:
The BSD 4.3 kernel used floated point arithmetic in its scheduler and later versions of FreeBSD likely inherited that. I have seen snippets of the source code and you can access the scheduler's internal floating point values by executing "uptime".
Why do you make claims that you could easily Google and find they're not true? FreeBSD does not use floats in the scheduler. Load averages are conceptually floating point values, but that doesn't mean the kernel needs to use the FPU to calculate them. The model scheduling algorithm is described in terms of real arithmetic, but it is implemented in terms of fixed-point. They shift up numbers into higher-order bits and use low-order bits to represent fractional components. This is standard practice in image processing and many other areas.

http://www.freebsd.org/cgi/cvsweb.cgi/s ... web-markup

From the source:
static fixpt_t   ccpu = 0.95122942450071400909 * FSCALE;   /* exp(-1/20) */
Note the type is explicitly marked fixpt_t (as in "fixed point"... as in not floating point).

*      1 - exp(-1/20) ~= 0.0487 ~= 0.0488 == 1 (fixed pt, *11* bits).
Again, fixed pt is explicitly stated. You could have found this yourself before posting that.

Shining Arcanine wrote:
I do have the source to Linux available and it uses floating point arithemetic:
# grep -r "float" /usr/src/linux-2.6.35.8 | wc -l
2390

# grep -r "double" /usr/src/linux-2.6.35.8 | wc -l
3253

Good god. A large percentage of those grep hits are in the kernel software floating-point emulation layer or the userland tools directory, not the kernel using floats! Again, it is possible to use MMX/SSE in the MD driver for RAID acceleration (which I mentioned), but it's not used in the scheduler, which was your original **** claim.
 
Crayon Shin Chan
Minister of Gerbil Affairs
Posts: 2313
Joined: Fri Sep 06, 2002 11:14 am
Location: Malaysia
Contact:

Re: Floating-point units in server-grade CPUs

Mon Nov 15, 2010 12:33 am

Let's assume the following is true:

Shining Arcanine wrote:
You can write a scheduler that does not use floating point arithmetic, but you would still need some sort of way of representing fractions and floating point arithmetic is convenient for that. Kernels use exponential moving averages in things like TCP/IP's RTT and various schedulers to keep track of trends. That is why if you want to compile one for a CPU that does not have a floating point unit on an ISA that normally does have them, you need to tell the compiler that so that it inlines functions that do floating point arithmetic with integer instructions in those cases. Otherwise, you get a kernel panic the moment an illegal instruction is executed in kernel code.


Ergo, we need FPUs after all. Can't we just get along?

EDIT: Kudos to whoever led SA to the above quotation.
Mothership: FX-8350, 12GB DDR3, M5A99X EVO, MSI GTX 1070 Sea Hawk, Crucial MX500 500GB
Supply ship: [email protected], 12GB DDR3, M4A88TD-V EVO/USB3
Corsair: Thinkpad X230
 
flip-mode
Grand Admiral Gerbil
Posts: 10218
Joined: Thu May 08, 2003 12:42 pm

Re: Floating-point units in server-grade CPUs

Mon Nov 15, 2010 12:27 pm

tfp wrote:
All you do is ignore what people post, nit pick things that don't matter to look right/knowledgable, and then spout off on items you have absolutely know really experience with. Discussing things to learn because one doesn't have all of the info is great but you are unwilling or unable to listen to anything that anyone has to say. SA, you just jump around on topics hoping to avoid the actual topic in its current form which you probably redirected by your ramblings, question avoidance, and quest to be "right". If you put even some of the effort you do posting this non-sense into listening and understanding you would actually be a resource to the forum instead of just flat out silly.

This. By the way, tfp, brace yourself because if SA bothers to respond to you it will be to lecture you for your use of ad-homen, despite the fact that you're just making a valid and oft repeated (by others) request that he simply try to be a more reasonable person.
 
cphite
Graphmaster Gerbil
Posts: 1202
Joined: Thu Apr 29, 2010 9:28 am

Re: Floating-point units in server-grade CPUs

Mon Nov 15, 2010 1:33 pm

Web servers and databases do not make any significant usage of floating point instructions.


Wrong and wrong. Floating point arithmetic is used extensively in web applications... aside from the examples that morphine mentions, he left out one major one which is encryption. Same applies to databases - I'd love to see your integer math solution for database encryption.

Video streaming servers are essentially file servers and need no floating point instructions to stream data. I doubt game servers and VoIP servers do either. Game servers likely do not have a heavy reliance on floating point performance.


Wrong again. Streaming video utilizes floating point math.

VoIP servers do digitial signal processing, which is usually floating point intensive, but that is not widely used.


But when it is used, it is largely dependent on floating point math.

Rendering is also quite possibly floating point intensive, but it is even less widely used than VoIP. As far as I know, render servers all run RenderMan. It was designed before GPGPU existed, so it originally ran on CPUs. Since it has enormous computing power requirements, I would expect Pixar to be porting it to GPUs.


So... you don't actually *know* whether or not it's floating point intensive (let me help: it is) but you're still willing to attempt to make authoritative statements about the direction it's going?
 
morphine
TR Staff
Posts: 11600
Joined: Fri Dec 27, 2002 8:51 pm
Location: Portugal (that's next to Spain)

Re: Floating-point units in server-grade CPUs

Mon Nov 15, 2010 1:38 pm

So... you don't actually *know* whether or not it's floating point intensive (let me help: it is) but you're still willing to attempt to make authoritative statements about the direction it's going?

You're late to the thread, aren't you? :lol:

Just kidding :)
There is a fixed amount of intelligence on the planet, and the population keeps growing :(
 
zqw
Gerbil
Posts: 53
Joined: Sun Dec 28, 2003 2:27 pm

Re: Floating-point units in server-grade CPUs

Mon Nov 15, 2010 3:30 pm

They don't all run RenderMan. There are many popular graphics algorithms that GPUs couldn't touch until dx11 capabilities. There are even more waiting on permissive memory models. We were actually excited about Larrabee, no joke. So ya, skip talking about this category.
 
Shining Arcanine
Gerbil Jedi
Topic Author
Posts: 1718
Joined: Wed Jun 11, 2003 11:30 am

Re: Floating-point units in server-grade CPUs

Wed Nov 17, 2010 11:47 pm

Crayon Shin Chan wrote:
Let's assume the following is true:

Shining Arcanine wrote:
You can write a scheduler that does not use floating point arithmetic, but you would still need some sort of way of representing fractions and floating point arithmetic is convenient for that. Kernels use exponential moving averages in things like TCP/IP's RTT and various schedulers to keep track of trends. That is why if you want to compile one for a CPU that does not have a floating point unit on an ISA that normally does have them, you need to tell the compiler that so that it inlines functions that do floating point arithmetic with integer instructions in those cases. Otherwise, you get a kernel panic the moment an illegal instruction is executed in kernel code.


Ergo, we need FPUs after all. Can't we just get along?

EDIT: Kudos to whoever led SA to the above quotation.


Tell your compiler that the instructions are illegal so that it does not use them and everything will be fine. There is no need for your CPU cores to have hardware floating point units on the account of your kernel, which has no significant dependence on floating point arithmetic.

cphite wrote:
Web servers and databases do not make any significant usage of floating point instructions.


Wrong and wrong. Floating point arithmetic is used extensively in web applications... aside from the examples that morphine mentions, he left out one major one which is encryption. Same applies to databases - I'd love to see your integer math solution for database encryption.


There are quite a few calculations being done in web browsers to make the calculations in web applications work. The fact that high level web applications use the calculations does not imply that the usage of floating point arithmetic is significant at the hardware level.

cphite wrote:
Video streaming servers are essentially file servers and need no floating point instructions to stream data. I doubt game servers and VoIP servers do either. Game servers likely do not have a heavy reliance on floating point performance.


Wrong again. Streaming video utilizes floating point math.


Streaming video is a file transfer with some special flow control added. It does not have any inherent dependency on floating point arithmetic. While versions that do transcoding do have such requirements, it is too computationally expensive to trans-code videos before streaming them from your servers unless you are Google or Netflix and if you were Google or Netflix, you would have multiple teams of engineers working for you that can write software that does these calculations on whatever processor architecture your datacenter uses. Since I assume that you are not Google or Netflix, the only thing you can do is send the bits as you have them on your disk. Otherwise, serving any significant quantity of users would bottleneck very quickly.

cphite wrote:
VoIP servers do digitial signal processing, which is usually floating point intensive, but that is not widely used.


But when it is used, it is largely dependent on floating point math.


VoIP is only intensive at the server-side and less than 1% of computers do it on a regular basis.

The meaning of the term significance is a key concept in this thread and I am not certain if people understand it. Finding a small pocket of instances of some event does not mean that the event occurs on a significant basis. The entire idea that floating point units in CPUs are not important is based on the notion of significance.

cphite wrote:
Rendering is also quite possibly floating point intensive, but it is even less widely used than VoIP. As far as I know, render servers all run RenderMan. It was designed before GPGPU existed, so it originally ran on CPUs. Since it has enormous computing power requirements, I would expect Pixar to be porting it to GPUs.


So... you don't actually *know* whether or not it's floating point intensive (let me help: it is) but you're still willing to attempt to make authoritative statements about the direction it's going?


I think you are reading more from my statements than is there to read. Saying that something is quite possibly <x> is a superset of saying that it is <x>. While being uncertain would imply saying that, saying that does not imply being uncertain. To assume such a thing is to affirm the consequent, which is wrong.
Disclaimer: I over-analyze everything, so try not to be offended if I over-analyze something you wrote.
 
TheEmrys
Minister of Gerbil Affairs
Posts: 2529
Joined: Wed May 29, 2002 8:22 pm
Location: Northern Colorado
Contact:

Re: Floating-point units in server-grade CPUs

Thu Nov 18, 2010 12:24 pm

Shining Arcanine wrote:
VoIP is only intensive at the server-side and less than 1% of computers do it on a regular basis.


Thus, we have arrived at the point where fpu's are indeed needed in server-grade CPU's. And it cannot be called insignificant, in that the entire IP telephony industry depends on this.

Oh, and by your definition, the number of servers with gpgpu's is "insignificant."
Sony a7II 55/1.8 Minolta 100/2, 17-35D, Tamron 28-75/2.8
 
Shining Arcanine
Gerbil Jedi
Topic Author
Posts: 1718
Joined: Wed Jun 11, 2003 11:30 am

Re: Floating-point units in server-grade CPUs

Thu Nov 18, 2010 1:30 pm

TheEmrys wrote:
Shining Arcanine wrote:
VoIP is only intensive at the server-side and less than 1% of computers do it on a regular basis.


Thus, we have arrived at the point where fpu's are indeed needed in server-grade CPU's. And it cannot be called insignificant, in that the entire IP telephony industry depends on this.

Oh, and by your definition, the number of servers with gpgpu's is "insignificant."


I think you misunderstand the scope of my comments. My comments only apply to CPUs where the majority of systems do not execute applications that significantly rely upon floating point operations (e.g. systems owned by most home users, most servers in datacenters, routers, mobile phones). Although there exist ways to avoid using floating point hardware in all circumstances, I never made the assertion that there are no applications where floating point hardware is heavily utilized (e.g. more than the integer hardware). I also never made the assertion that such applications should use the same CPUs that everyone else uses. Applications that heavily rely on floating point operations should either use CPUs specifically designed, custom logic or in many cases, GPUs.

This thread was originally part of the Bulldozer thread, but I asked an existential question regarding the importance of the discussion itself that took the discussion in a direction that morphine did not like. The thread title is a poor description of the question I asked. If you want to argue about that with someone, you could argue with morphine. He wrote it.
Disclaimer: I over-analyze everything, so try not to be offended if I over-analyze something you wrote.
 
TheEmrys
Minister of Gerbil Affairs
Posts: 2529
Joined: Wed May 29, 2002 8:22 pm
Location: Northern Colorado
Contact:

Re: Floating-point units in server-grade CPUs

Thu Nov 18, 2010 2:46 pm

Your entire premise was to replace the fpu in servers with gpgpu's which simply cannot work at this point in time. And attempting to blame an admin for appropriately doing their job is compeltely off-base.
Sony a7II 55/1.8 Minolta 100/2, 17-35D, Tamron 28-75/2.8
 
tfp
Grand Gerbil Poohbah
Posts: 3413
Joined: Wed Sep 24, 2003 11:09 am

Re: Floating-point units in server-grade CPUs

Thu Nov 18, 2010 2:56 pm

Try to keep up he is arguing a different point now. The past is long gone and forgotten :lol: .
 
cphite
Graphmaster Gerbil
Posts: 1202
Joined: Thu Apr 29, 2010 9:28 am

Re: Floating-point units in server-grade CPUs

Thu Nov 18, 2010 3:24 pm

There are quite a few calculations being done in web browsers to make the calculations in web applications work. The fact that high level web applications use the calculations does not imply that the usage of floating point arithmetic is significant at the hardware level.


One minute you're claiming that web servers and databases do not utilize floating point instructions; now you're limiting it to high level web applications? Do you really think that nobody notices when you try to change your argument in mid-stream?

Streaming video is a file transfer with some special flow control added. It does not have any inherent dependency on floating point arithmetic. While versions that do transcoding do have such requirements, it is too computationally expensive to trans-code videos before streaming them from your servers unless you are Google or Netflix and if you were Google or Netflix, you would have multiple teams of engineers working for you that can write software that does these calculations on whatever processor architecture your datacenter uses. Since I assume that you are not Google or Netflix, the only thing you can do is send the bits as you have them on your disk. Otherwise, serving any significant quantity of users would bottleneck very quickly.


Research the difference between file serving and video streaming.

VoIP is only intensive at the server-side and less than 1% of computers do it on a regular basis.


Well, since we're talking about server-grade CPUs the implication is that we're talking about servers. As for the "1%" that I am assuming was pulled from your butt, the fact of the matter is that 100% of servers used by VoIP providers "do it" on a regular basis.

The meaning of the term significance is a key concept in this thread and I am not certain if people understand it. Finding a small pocket of instances of some event does not mean that the event occurs on a significant basis. The entire idea that floating point units in CPUs are not important is based on the notion of significance.


So... according to you, the entire telecom industry, the entertainment industry, and any businesses in general that have a need to store and transmit data over a secure connection, amount to a "small pocket of instances" that use FP? Gosh, I can't imagine why you aren't taken more seriously...

I think you are reading more from my statements than is there to read. Saying that something is quite possibly <x> is a superset of saying that it is <x>. While being uncertain would imply saying that, saying that does not imply being uncertain. To assume such a thing is to affirm the consequent, which is wrong.


I think that you are reading more from your statements than there is to read, by a wide margin, at least in regards to any sort of valid argument.
 
flip-mode
Grand Admiral Gerbil
Posts: 10218
Joined: Thu May 08, 2003 12:42 pm

Re: Are the Bulldozer FP capabilities being underestimated?

Thu Nov 18, 2010 4:05 pm

Shining Arcanine wrote:
morphine wrote:
Shining Arcanine wrote:
Would someone enlighten me as to why people care about floating point performance?

Because at this point in time close to zero of the commonly-used server software is OpenCL/CUDA/whatever enabled?


Did you know that close to zero of the commonly-used server software requires a floating point unit?

Shining Arcanine wrote:
I think you are reading more from my statements than is there to read.

:roll: Yeah, people should stop reading "too much" into sweeping statements.

Does it mortally embarrass you to ever concede a point? There is nothing, nothing wrong or weak or inferior about an appropriate measure of humbleness. It's perfectly useful and here are some practical examples of how to employ it:

Oops, my bad.
Ah, I see your point.
Hmm, I hadn't thought of that.
Oh, good point - thanks!
Well, yeah, I guess so.
Ugh, my brain isn't functioning well today.
Right, um, I need some coffee.
Well that's what I get for drinking and posting.

Just think, you could have looked so much better and avoided this whole thread if the above quote had happened like this:
Shining Arcanine wrote:
morphine wrote:
Shining Arcanine wrote:
Would someone enlighten me as to why people care about floating point performance?

Because at this point in time close to zero of the commonly-used server software is OpenCL/CUDA/whatever enabled?
That's true.

But, no, instead, you've to convince us it's not your foot you've tasted ten times in this thread, but a fine fillet. :roll:
 
Shining Arcanine
Gerbil Jedi
Topic Author
Posts: 1718
Joined: Wed Jun 11, 2003 11:30 am

Re: Floating-point units in server-grade CPUs

Thu Nov 18, 2010 9:45 pm

TheEmrys wrote:
Your entire premise was to replace the fpu in servers with gpgpu's which simply cannot work at this point in time. And attempting to blame an admin for appropriately doing their job is compeltely off-base.


That is your premise, not mine. The only premises I have are the following:

  1. Floating Point Units are not needed in CPUs for the things that the majority of systems containing them are expected to do.
  2. Most floating point calculations benefit enough from being done on GPUs (i.e. they are stream calculations) that they should be processed there (i.e. on stream processors).
  3. The majority of servers do not do any significant quantity of floating point calculations to need floating point hardware.

cphite wrote:
There are quite a few calculations being done in web browsers to make the calculations in web applications work. The fact that high level web applications use the calculations does not imply that the usage of floating point arithmetic is significant at the hardware level.


One minute you're claiming that web servers and databases do not utilize floating point instructions; now you're limiting it to high level web applications? Do you really think that nobody notices when you try to change your argument in mid-stream?


If you want to know what I really think, then I will tell you. You are more interested in attempting to contradict me than you are in saying something that is correct. There is a fundamental difference between what a web browser does and what a web server does and unless you understand the difference, you definitely should not try to correct those who do.

By the way, neither web browsers nor web servers make significant use of floating point calculations as far as the effect on performance is concerned. While I am sure that you could make an Apache module or a Javascript that does a floating point calculation in an infinite loop, such heavy usage of floating point arithmetic does not occur in practice. Also, while it is true that the phase "high level" with reference to web applications that run in web browsers is exclusionary, that has more to do with the fact that "low level" equivalent would mean you could embed assembly code into Javascript, which the EMCAScript specification does not support.

cphite wrote:
Streaming video is a file transfer with some special flow control added. It does not have any inherent dependency on floating point arithmetic. While versions that do transcoding do have such requirements, it is too computationally expensive to trans-code videos before streaming them from your servers unless you are Google or Netflix and if you were Google or Netflix, you would have multiple teams of engineers working for you that can write software that does these calculations on whatever processor architecture your datacenter uses. Since I assume that you are not Google or Netflix, the only thing you can do is send the bits as you have them on your disk. Otherwise, serving any significant quantity of users would bottleneck very quickly.


Research the difference between file serving and video streaming.


Sending a file from one computer to another is file streaming. Sending a video from one computer to another is video streaming. There is not much more to it than that.

cphite wrote:
VoIP is only intensive at the server-side and less than 1% of computers do it on a regular basis.


Well, since we're talking about server-grade CPUs the implication is that we're talking about servers. As for the "1%" that I am assuming was pulled from your butt, the fact of the matter is that 100% of servers used by VoIP providers "do it" on a regular basis.


If you want to talk about "server-grade CPUs", talk to morphine, or better yet, start your own thread. Morphine named the thread when he split it from a thread talking about floating point performance in AMD's Bulldozer CPU. While Bulldozer will certainly be used in servers, it is certainly not "server-grade", so nothing in this thread is about "server-grade CPUs".

By the way, when I talk about computers, I refer to anything that has a CPU. That includes cellphones, routers, desktops, laptops, set-top boxes, etcetera. Whether you believe it or not, less than 1% of those do VoIP. Also, I doubt that 100% of VoIP providers' servers do VoIP. Their web servers are likely dedicated to hosting their websites. There are also other internal servers that would be dedicated to managing their organizations' logins and other things that would not be used for any VoIP stuff either.

cphite wrote:
The meaning of the term significance is a key concept in this thread and I am not certain if people understand it. Finding a small pocket of instances of some event does not mean that the event occurs on a significant basis. The entire idea that floating point units in CPUs are not important is based on the notion of significance.


So... according to you, the entire telecom industry, the entertainment industry, and any businesses in general that have a need to store and transmit data over a secure connection, amount to a "small pocket of instances" that use FP? Gosh, I can't imagine why you aren't taken more seriously...


I doubt any encryption algorithm using floating point calculations is in use. In order for one to work, it would need to avoid rounding issues by restricting operations to the bits contained in the mantissa, which would mean emulating integer arithmetic with floating point numbers. If you think that businesses use floating point calculations to do secure communications, please name the algorithm that they use and explain how it uses floating point arithmetic. Using floating point arithmetic for encryption would cause a performance penalty, so I would be surprised if you could find anyone doing that.

cphite wrote:
I think you are reading more from my statements than is there to read. Saying that something is quite possibly <x> is a superset of saying that it is <x>. While being uncertain would imply saying that, saying that does not imply being uncertain. To assume such a thing is to affirm the consequent, which is wrong.


I think that you are reading more from your statements than there is to read, by a wide margin, at least in regards to any sort of valid argument.


Have you ever had a genuine disagreement with someone where you did not hurl insults at them?
Disclaimer: I over-analyze everything, so try not to be offended if I over-analyze something you wrote.
 
ekul
Gerbil
Posts: 81
Joined: Thu Jan 17, 2008 1:25 pm

Re: Floating-point units in server-grade CPUs

Sat Nov 20, 2010 2:33 pm

No one has brought up the Niagara chip yet so it would be worth spending some time on. Sun has actually designed and sells (Oracle now, boo) a series of SPARC CPUs that have limited floating point units. These CPUs are designed to be "thread monsters" with limited single thread performance. The machine gun design is quite cool since it's SMT on steroids. There have been three Niagaras:

T1: 1.2 GHz, 8 cores/chip, 4 threads/core, single socket
1 FPU/chip

T2: 1.6 GHz, 8 cores/chip, 8 threads/core, dual socket
1 FPU/core and 1 encryption engine/core

T3: 1.67 GHz, 16 cores/chip, 8 threads/core, quad socket
1 FPU/core and 1 encryption engine/core

T series Sun servers eat database and web applications for lunch and scale to insane numbers of users for 4U servers. The fact Sun includes 2x10Gbit ethernet interfaces on the chips (not the boards, the CPUs) should give an indication of the kind of bandwidth these servers are expected to handle. The encryption engine even means you can do AES for free. Very cool.

Sun dropped to a single FPU shared between 8 cores in the T1. They also had a tool to analyse programs to see if they would be suitable for Niagara and it didn't recommend anything over 1-3% fp instructions. In T2 and again in T3 they have 1 FPU and an encryption unit per core. They doubled thread count from T1 to T2 but increased FP capacity a lot more than that. There must be a reason for this and it's because Sun received complaints from customers that they liked the T series but couldn't use them if their application used even a small number of fp instructions.

Sun actually did what the original poster claimed would save all kinds of space and power and (mostly) removed the floating point from a server chip. They then came back with a design that is still heavily tilted towards integer performance but at least has 1 FPU for every physical core.
 
Shining Arcanine
Gerbil Jedi
Topic Author
Posts: 1718
Joined: Wed Jun 11, 2003 11:30 am

Re: Floating-point units in server-grade CPUs

Sat Nov 20, 2010 3:43 pm

Ideally, programs would be recompiled to make the most efficient usage of the chip by replacing floating point operations with integer instructions. It sounds like the people who complained either did not do that or were using the processors for things that it was not meant to process, like scientific computing.

By the way, I did mention how Sun/Oracle de-emphasized single thread performance earlier in the thread. I really did not post much about it because the focus was more on Bulldozer.

Oracle's Niagara architecture is designed according to that philosophy
Disclaimer: I over-analyze everything, so try not to be offended if I over-analyze something you wrote.
 
ekul
Gerbil
Posts: 81
Joined: Thu Jan 17, 2008 1:25 pm

Re: Floating-point units in server-grade CPUs

Sat Nov 20, 2010 4:08 pm

Shining Arcanine wrote:
Ideally, programs would be recompiled to make the most efficient usage of the chip by replacing floating point operations with integer instructions. It sounds like the people who complained either did not do that or were using the processors for things that it was not meant to process, like scientific computing
[/quote]

Recompiling really isn't the answer since T-series mostly run j2ee applications. Those can be re-compiled for free by the jvm. Sun could have built a JVM for niagara that doesn't use fp instructions even when they are requested for a lot less money then it takes to build a whole new chip. But they didn't. They included more fp hardware. Doing fixed point with integers is slow and takes a lot of memory. That's why POWER7 and IBM Mainframes have binary decimal support.

If your point was servers don't generally need insane FP and SIMD units like the ones found in westmere or upcoming in sandybridge then I would tend to agree. But based on Sun's experience and the fact it's silly to have a separate die for FP/SIMD when you don't need one the case for no floating point is pretty thin.
 
Shining Arcanine
Gerbil Jedi
Topic Author
Posts: 1718
Joined: Wed Jun 11, 2003 11:30 am

Re: Floating-point units in server-grade CPUs

Sat Nov 20, 2010 5:26 pm

ekul wrote:
Shining Arcanine wrote:
Ideally, programs would be recompiled to make the most efficient usage of the chip by replacing floating point operations with integer instructions. It sounds like the people who complained either did not do that or were using the processors for things that it was not meant to process, like scientific computing


Recompiling really isn't the answer since T-series mostly run j2ee applications. Those can be re-compiled for free by the jvm. Sun could have built a JVM for niagara that doesn't use fp instructions even when they are requested for a lot less money then it takes to build a whole new chip. But they didn't. They included more fp hardware. Doing fixed point with integers is slow and takes a lot of memory. That's why POWER7 and IBM Mainframes have binary decimal support.

If your point was servers don't generally need insane FP and SIMD units like the ones found in westmere or upcoming in sandybridge then I would tend to agree. But based on Sun's experience and the fact it's silly to have a separate die for FP/SIMD when you don't need one the case for no floating point is pretty thin.


Considering that Sun Microsystems was a hardware company, modifying their hardware so that they could sell upgrades was probably far more appealing to their executives than modifying their software so that customers would not need upgrades for longer periods of time. If you were making decisions at Sun Microsystems, what decision would you have made?
Disclaimer: I over-analyze everything, so try not to be offended if I over-analyze something you wrote.
 
Glorious
Gerbilus Supremus
Posts: 12343
Joined: Tue Aug 27, 2002 6:35 pm

Re: Floating-point units in server-grade CPUs

Mon Nov 22, 2010 9:07 am

SA wrote:
Ideally, programs would be recompiled to make the most efficient usage of the chip by replacing floating point operations with integer instructions. It sounds like the people who complained either did not do that or were using the processors for things that it was not meant to process, like scientific computing


Even if everything you say is true theoretically, it is nevertheless the case that even enterprise-level customers for whom performance is critical are obviously using floating point. If they are, you cannot emulate it faster than you can do it in hardware. Are you seriously suggesting otherwise?

SA wrote:
Considering that Sun Microsystems was a hardware company, modifying their hardware so that they could sell upgrades was probably far more appealing to their executives than modifying their software so that customers would not need upgrades for longer periods of time.


How is Sun supposed to modify their customer's software? If they used floating point, they used floating point. You can recompile their software, but you cannot rewrite it.

SA wrote:
If you were making decisions at Sun Microsystems, what decision would you have made


A decision based on physical reality, which is something that evidently eludes your grasp.
 
Waco
Maximum Gerbil
Posts: 4850
Joined: Tue Jan 20, 2009 4:14 pm
Location: Los Alamos, NM

Re: Floating-point units in server-grade CPUs

Tue Nov 23, 2010 1:13 pm

I just want to say thank you to everyone for this immensely entertaining thread. Made my morning much more enjoyable reading it while waiting for **** to compile. :)
Victory requires no explanation. Defeat allows none.
 
cphite
Graphmaster Gerbil
Posts: 1202
Joined: Thu Apr 29, 2010 9:28 am

Re: Floating-point units in server-grade CPUs

Tue Nov 23, 2010 2:17 pm

TheWacoKid wrote:
I just want to say thank you to everyone for this immensely entertaining thread. Made my morning much more enjoyable reading it while waiting for **** to compile. :)


Well, maybe if you'd made proper use of floating point hardware it wouldn't have taken all morning :b
 
JustAnEngineer
Gerbil God
Posts: 19673
Joined: Sat Jan 26, 2002 7:00 pm
Location: The Heart of Dixie

Re: Floating-point units in server-grade CPUs

Tue Nov 23, 2010 2:19 pm

cphite wrote:
Well, maybe if you'd made proper use of floating point hardware it wouldn't have taken all morning :b
He must not be using a compiler that's properly optimized for GPGPU. :wink:
 
Shining Arcanine
Gerbil Jedi
Topic Author
Posts: 1718
Joined: Wed Jun 11, 2003 11:30 am

Re: Floating-point units in server-grade CPUs

Tue Nov 23, 2010 9:51 pm

JustAnEngineer wrote:
cphite wrote:
Well, maybe if you'd made proper use of floating point hardware it wouldn't have taken all morning :b
He must not be using a compiler that's properly optimized for GPGPU. :wink:


I have written most of a compiler for one of my computer science classes this semester. So far, I have implemented Lexical Analysis, Parsing, Abstract Syntax Tree Generation and Type Checking. I have not yet done Intermediate Code Generation, assembly output and the various levels of optimization, although in principle, I am capable of doing it.

Anyway, compilers do not use floating point operations outside of optimization passes involving constant propagation.

http://en.wikipedia.org/wiki/Constant_folding

Furthermore, while you can write a compiler that runs on GPU, compilation does not fall into the category of stream processing, so a traditional compiler on a CPU would likely run circles around any compiler that both runs on a GPU provided that the two are roughly equivalent in terms of the optimization passes that they do.

Be careful when talking about whether or not a compiler is "optimized" for a GPU. Talking about any kind of optimization when talking about compilers means having the compiler perform it for the target program, rather than attempting to optimize the compiler itself. Optimizing a compiler is not a major concern for computer scientists outside of certain NP-complete issues that modern compilers workaround. Also, talking about optimization is a misnomer when discussing compilers, because having something be optimal means that it cannot become better and what a compiler does is implement heuristics that are known to make code better in general. Doing complete optimization is a NP-complete problem and unless P = NP, I can guarentee that you will die long before you can compile a program (e.g. Windows) and receive truly optimized output from the compiler.

By the way, in the last decade, requirements for degrees in computer science have been relaxed so compiler theory is no longer required everywhere, but computer scientists traditionally were required to study compiler theory and you can expect that all of the professors in any serious computer science department are intimately knowledgeable in this area. I can guarantee that you will be thrown out of any serious computer science department if you suggest that making proper usage of floating point hardware makes compilers run faster. If you think otherwise, then I challenge you to produce code for a compiler that sees a benefit. I would be interested in seeing it.
Last edited by Shining Arcanine on Tue Nov 23, 2010 10:11 pm, edited 2 times in total.
Disclaimer: I over-analyze everything, so try not to be offended if I over-analyze something you wrote.
 
SNM
Emperor Gerbilius I
Posts: 6209
Joined: Fri Dec 30, 2005 10:37 am

Re: Floating-point units in server-grade CPUs

Tue Nov 23, 2010 9:56 pm

And let's give his straight face a hand, folks, he'll be here all week! :lol:
Core i7 920, 3x2GB Corsair DDR3 1600, 80GB X25-M, 1TB WD Caviar Black, MSI X58 Pro-E, Radeon 4890, Cooler Master iGreen 600, Antec P183, opticals

Who is online

Users browsing this forum: No registered users and 1 guest
GZIP: On