Computing desk
< December 2	<< Nov \| December \| Jan >>	December 4 >

Welcome to the Wikipedia Computing Reference Desk Archives
The page you are currently viewing is an archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.

December 3

Mobo Hunt

I am searching for a motherboard which can accomodate: · two Intel Xeon E5-2695 v2 2.4GHz Processors · two Dual-Width x16 PCIe 3.0 Graphics Cards, and · four Single-Width x8 PCIe 2.0 Cards

Does anybody here have any ideas where to look, or know a suitable mobo? 13:31, 3 December 2013 (UTC)

Sure... how about SuperMicro's Xeon Socket2011 selection? There are certain rack mount systems that have such preposterously immense PCIe capabilities: for example, X9DRG supports: " 4 x16 PCI-E 3.0 slots, 1 x8 PCI-E 3.0 (in x16), & 1 x4 PCI-E 2.0 (in x8) slot." Realistically, at this price point, you can phone up the manufacturer (you have a rep, right?) and request that they re-socket the PCIe lanes in the configuration you are seeking, and run a small volume manufacture for you. Nimur (talk) 16:51, 3 December 2013 (UTC)[reply]

Or, a little more friendly for the small-business supercomputer: the X9DRW-3LN4F provides one 48x PCIe riser slot. You can build your own rack-mount chassis above, using any combination of PCIe risers to break that into the lane allocations as you see fit. You might also need some custom device software to make this do what you expect... this is documented in the Core i7 manual under PCIe port bifurcation. Nimur (talk) 18:00, 3 December 2013 (UTC)[reply]

Yikes! I don't know anything about building a rackmount chassis or PCIe port bifurcation. I was hoping for an EATX mobo that would fit in a Supermicro CSE-747TQ-R1400 tower chassis. 119.56.117.57 (talk) 10:38, 4 December 2013 (UTC)[reply]

...You might want to learn, before you commit to spending upwards of $5000 per system on CPUs alone. Are you sure you need what you are asking for? Are you willing to shell out five- and six-figure US-dollar quantities for technical features that you aren't using? Nimur (talk) 19:18, 4 December 2013 (UTC)[reply]

Those PCIe requirements are extreme for anything remotely consumer-grade. You're asking not only for 64 lanes, which is going to be tough to find (the one linked above only has 48), but for those lanes to be in a specific configuration as well. If you don't mind sharing, you could let us know what you're trying to accomplish that has those requirements - maybe we can help with alternative solutions? Katie R (talk) 19:19, 4 December 2013 (UTC)[reply]

Asus makes the Z9PE-D8 that has 7 x16 slots, so it could work, but unless I'm picturing it wrong, you're going to be one slot short because of the double-width requirement. Is this a personal project, or is this something you're building for a business? I could get you contact information for the vendor we use for this sort of request, but they won't do much for you if this one motherboard is the only sale they'll ever get through you. Katie R (talk) 20:29, 4 December 2013 (UTC)[reply]

Well, there's a mismatch between the motherboard and the CPU's published capabilities. Somebody is making up hardware specs, and I'm betting it isn't Intel: Intel only supports 40 lanes per chip: which you can confirm by reading Intel's E5-2695 quick technical overview. So, if there are two CPUs each providing 40 lanes, and the motherboard has "7 x16 slots", where are these PCIe devices going? Some of those are "phony" x16 slots. At best, you can configure which lanes are going to each socket. But even that is dubious; because the Asus motherboard uses the 602 PCH, for a total of 8 PCIe lanes per PCH (...or, 16 total PCIe lanes on the board - far short of the implied "7 x16" - by a factor of seven times!) (Actually, the clarification is provided in the fine-print of the logic board's specifications, so Asus is not totally misrepresenting its capability).

You can put as many connector-sockets as you desire on a motherboard, but they aren't 16-lanes wide unless all sixteen lanes are connected to the PCIe root. This Asus board is either a fantastic piece of engineering marvel (perhaps it was designed for a custom use-case); or it is an addled and under-performing platform that was produced a very confused novice computer engineer. Nimur (talk) 21:31, 4 December 2013 (UTC)[reply]

The two dual-width x16 PCIe 3.0 cards are an Nvidia Quadro K5000 Graphics Card and an Nvidia Tesla K20X GPU Compute Card, for an Nvidia Maximus configuration.

This new workstation (for which the budget is US$30K) is for running Autodesk 3D Studio Max in a small-business context, also involving the use of MotionBuilder and Mudbox.

It is to replace the current workstation, which is built on a Tyan S7025WAGM2NR mobo in a Supermicro CSE-747TQ-R1400 chassis, with 2x X5690's, 48GB RAM, a Quadro 6000, and a Tesla C2075. It's already been upgraded once, from W5580's to X5690's, and I was hoping to re-use the chassis, as it's still in nearly pristine condition after four years.

I've already bought the two Intel Xeon E5-2695 v2 2.4GHz processors (which cost US$2,247 each, with taxes) and the two Nvidia cards (which together cost US$5,885 - also with taxes).

I actually intend to install only three x8 PCIe 2.0 cards, but would prefer to have a fourth slot for future expansion. The Asus Z9PE-D8 might do (as the Tesla will overhang the edge of the mobo, not cover one of the PCIe slots), but I'll have to research its quality and reliability first.

119.56.116.39 (talk) 07:49, 5 December 2013 (UTC)[reply]

(This is a response to Nimur's concerns as well) From the basic specs, it sounds like some slots are x8 slots that duplicate the lanes of adjacent x16 slots - so you can use one double-width x16 card or 2 x8 cards. This shouldn't be an issue for your application, but I would find the manual online and double-check that the right number of lanes make it to the slots you'll need to use. It says it supports 4 Teslas, which implies that the bottom slot must be x16, and they expect the last card to hang over the edge like you describe. Katie R (talk) 13:46, 5 December 2013 (UTC)[reply]

Long time later, but I just wanted to point out the practice of putting x8 lanes and sometimes even x4 lanes on a x16 slot isn't actually unusual. Even our article PCI Express mentions it (and it's correct to call it a x16 slot), and it's the only way to support a graphics card with x8 or fewer lanes as the practice of having an open slot which some manufacturers tried in the early days is not recommended. And no one produces GPUs in an x8 config.

The Asus site ideally should have mentioned in the summary how their board was configured, but in reality most manufacturers reserve such nitty gritty for their spec sheet. While 7 slots does seem a bit extreme, 3 way SLI or Crossfire using only 8 lanes for each isn't uncommon and whenever I've looked in to benchmarks the actual advantage for x16 lanes is minimal, particularly in a dual or single card config. (And remember we'e still in somewhat early days for for PCI Express 3.0.)

Although interestingly Nvidia does disable SLI with x4 lanes [1] even though as you can see here with 3 way Crossfire, with 2 cards on x4 lanes [2] doesn't seem to be much of a disadvantage unless it comes from the chipset instead of the CPU.

It may be things are different in the GPGPU world but I doubt it. (No idea about the Xeon Phi however.)And since you don't actually need to share data depending on your program, I imagine 7 cards with 8 lanes each is potentially little different from 1 with 8 lanes or for that matter one with 16 lanes, in terms of now each card would perform. Presuming the CPU, memory and system bus can support that many. Remembering also, you'd need a single width i.e. weaker card (but these are often better price performance wise).

In other words, while the Asus mobo is obviously fairly specialised, it sounds like it would be useful to some. Of course for such an expensive system it may not be worth skimping on the lanes but it may also not be worth overspeccing it unnecessarily and if you're choosing weaker cards you are probably worried about cost. In any case, as has been pointed out, this is a moot point to the OP since it can have 4 x16 slots with x16 lanes if you don't use the other slots.

P.S. Note x8 and x4 slots seem to be dying out in much of the consumer word I presume because putting the x4 and x8 lanes in to an x16 slot is easy and has a marketing and usability advantage. So if you do have a few x4 or x8 cards, you'd have another use case for the slots even if you don't need the x16 physical slot. [3] [4]

P.P.S. Forgot to mention, if you setting up a computer for high end professional or research work, getting something like a Supermicro rather than an Asus which is more targeted at the consumer market is obviously worth considering. But I don't think Asus or similar manufacturers should be ignored completely for certain setups, such as those looking for a high performance but relatively cheap systems using more consumer grade stuff such as graphic cards rather than GPGPU cards, despite the risks, possible support and compatibility issues and intentional limitations imposed. And some people seem happy to choose such systems.

Nil Einne (talk) 08:36, 3 January 2014 (UTC)[reply]

Reals in Jython

I'm just researching some information on JES programming for my introduction to Information Technology at Melbourne's RMIT. I have unsuccessfully tried to source the answer elsewhere, if anybody can help me I would be much obliged, David Smith.

Why in Jython, (JES) do we get the output 3.9000000000000004 from 1.3 * 3?

and

Why do we get the output in Jython 0.3333333333333333 when we print 1.0 / 3?

Thank you.

David Smith. — Preceding unsigned comment added by Thesmithster (talk • contribs) 21:13, 3 December 2013 (UTC)[reply]

I don't know Jython but computers and programs usually store real numbers as binary floating point. 1.3 and 1/3 have no finite exact representation in binary so rounding occurs. For example, 1.3 may be rounded to a binary number close to 1.3000000000000001. Multiply by 3 and the result when written in decimal may be rounded to 3.9000000000000004. PrimeHunter (talk) 22:48, 3 December 2013 (UTC)[reply]

It is technically rounding, but I find it more helpful to realize that every (finite) floating point number is a dyadic rational. In decimal, all these that are not integers end in "5": 1/2=0.5, 1/4=0.25, 3/4=0.75, 3/8=0.325, etc. Of course, for more negative powers of 2, the decimals are longer: 1/1024=0.0009765625. Those are your choices, so when you want to approximate 1.3, your closest IEEE 754 double choice is 1.3000000000000000444089209850062616169452667236328125 (5854679515581645/2⁵²); the next lower choice 5854679515581644/2⁵²=1.29999999999999982236431605997495353221893310546875. The exact triple of this quantity is of course 3.9000000000000001332267629550187848508358001708984375, to which the closest double is 3.9000000000000003552713678800500929355621337890625. This is the result you obtained (so the rounding error in the multiplication was as small as possible); the choice to represent it as 3.9000000000000004 (rather than, say, 3.90000000000000036, which is in a technical sense more precise) is a subtle one: rounding to 17 significant figures happens to be necessary and sufficient to avoid having any two double values collide. The unfortunate rounding is actually in representing 1.3; the error in it, multiplied by 3, causes the difference between the observed value and the closest double to 3.9 (3.899999999999999911182158029987476766109466552734375, which we know displays as "3.9" or "3.9000" or so because of another subtle argument about decimals with less than 16 significant digits). --Tardis (talk) 01:05, 4 December 2013 (UTC)[reply]

See also: [5] →Σ σ ς. (Sigma) 06:14, 4 December 2013 (UTC)[reply]

Of course, if you wish to have your arithmetic behave in a more "intuitive" way you can represent decimals with the decimal module in Jython. I haven't looked into the implementation details, but I imagine there is a significant performance penalty as the floating-point unit can't be utilised directly. Equisetum (talk | contributions) 11:28, 4 December 2013 (UTC)[reply]

If Jython's decimal is a wrapper over Java's java.math.BigDecimal (which I think it will be), a 2009 benchmark shows a two order of magnitude slowdown, compared with Java's IEEE double type - about what I'd expect. -- Finlay McWalterჷTalk 16:02, 4 December 2013 (UTC)[reply]

By the way - why do programming languages still use floating point representation for rational numbers? With all the processing power we have, I'd think they'd have a numeric type "rational" with a specific representation of the repeating digits, and reserve floating point only for irrational numbers at most. Wnt (talk) 14:44, 4 December 2013 (UTC)[reply]

Many languages do support a rational data type, either in the native language or in a library extension. See rational data type for examples. Gandalf61 (talk)

Interesting page. Come to think of it, I suppose there is a reason: with some languages like C, I think you can pretty much count on ordinary instructions to run in fairly constant time; but handling ratios means reducing ratios means integer factorization, for which any polynomial time is still elusive. Thinking about it, I suppose the problem isn't that it's much slower but that it could be slower to an unlimited degree. Wnt (talk) 00:18, 5 December 2013 (UTC)[reply]

Instead of integer factorization, dividing by the least common divisor can be used, and that can be found much faster than factoring. Bubba73 ^{You talkin' to me?} 02:53, 5 December 2013 (UTC)[reply]

"I think you can pretty much count on ordinary instructions to run in fairly constant time..." If only! Between cache misses, super-scalar out of order execution, and dynamic frequency scaling, constant cycles-per-execution is about the last thing you can rely on, with modern computers! Intel doesn't even put ballpark values for clock-cycles per machine-instruction in its reference manuals anymore. In real, big CPUs, you can't know how long one instruction will take until you execute it. What this means in practice is that the only really really real real time operating systems are the ones that run on very primitive microcontrollers, without DRAM and without any caches and without any buffers and without any interrupt-driven I/O, and generally without any of the computer architecture features that have been standard since the 1950s.

WP:OR: I've even managed to make a single instruction (a pointer dereference, something pretty much equivalent to movl) to require macroscopic amounts of time - thousands of seconds - to complete its execution. It wasn't easy, and I'm not even really sure how I did it, but nobody was happy when I made that happen, least of all myself.

Anyway, the C language specification doesn't imply or encourage machine implementations to have specific execution times for any operations. This kind of assumption isn't built into the language specification in any way whatsoever; nor is it implied by most implementations. A great counter-example is software floating-point emulation. For example, if you use gcc, the compiler can accept -msoft-float - and the exact same C code - for example, x*2.0 or " (a + ib) / (c + id))", can either compile into "primitive data operations" that execute as single machine-instructions; or elaborate software functions implementing algorithms with a priori unknown runtimes. Nimur (talk) 01:27, 5 December 2013 (UTC)[reply]