Dual Core Technology

We are about to swap out an old Enterprise Windows server in our Xe environment. We are trying to decide between a 2 way Dual core and a straight up 4 way box. Has anyone had any experience in this area?

Thanks

I have an eight way, dual core cluster as my enterprise server. It cranks!

I've seen some recent benchmarks which say there is no real advantage of a 4-way versus a dual processor box with dual cores. Intel basically glues two processors, or cores, together into one package. This is different than the AMD approach. The Intel architecture isn't as efficient as the AMD Opteron due to the lack of an integrated memory controller. AMD has an integrated DDR memory controller with each core having dedicated L2 cache. Intel shares this between the two cores. This means that, depending on your task, a dual core Opteron system may offer better performance than a comparably priced Intel system.

With JDE, you may not notice much difference between the two.

[ QUOTE ]

I have an eight way, dual core cluster as my enterprise server. It cranks!


[/ QUOTE ]

I'm not sure thats what the user wanted to hear !

The question is - 2-way Dual Core vs Quad-way single core - which is fastest ?

First of all, you need to compare the costs for these. A 2-way should be less expensive per the motherboard than a 4-way - so these costs will be especially important. A 2-way dual core box WILL look the same to the OS as a 4-way single processor machine - so if your objective is to save some cash by buying dual core, you'll be fine.

However, if your objective is to buy the fastest processor architecture available - then single-core is going to be the right direction FOR SINGLE THREADED APPLICATIONS (like JDE prior to 8.95 !) as such, a single-core 4-way will outperform the slower dual-core 2-way (I've benchmarked both). If you're on 8.95 then the UBE processes will multi-thread, and it will take advantage of the dual-core processors.

I run single-core application servers on our Xe implementation against dual-core Opteron AMD processors for the database server - we have the option of going 64bit on the database server and we have multiple intel application servers running as fast as we could get.

Awesome!
Thank you for the help...

What evidence do you have of mult-threaded UBE's with 8.95? I understand this to not be the case - they support Call Object kernel multithreading (and ONLY if you have 8.95 with 8.11 SP1 applications - then only if you enable the multi-threaded kernel option) but I've been told the UBE's do not do this.

[ QUOTE ]

What evidence do you have of mult-threaded UBE's with 8.95?


[/ QUOTE ]
If UBE's do not multi-thread, then theres even less of a reason to go dual core - and my argument is supported even more.

I would EXPECT the UBE's to run the same callobjects as any other written application however, so I'd expect UBE's to multi-thread - and my information came from another source on pretty much the same subject as this.

However, I haven't set up 8.95 with multi-threading yet - so I reserve my comments on this. I will be running a benchmark over the next few months however.

I have 8.11 SP1 apps (8.95 is required) with multithreading enabled. It basically allows business functions to process in another thread rather than waiting behind a long running business function sitting on a specific Call Object kernel. Dual core or dual processor, it doesn't matter - it likes both. It's great for web clients if you have a lot of activity on an application server, but UBE's are another story.

What I want to point out about "going dual core" is that you really won't have much choice in the future.

Performance does not degrade with a second core for single-threaded apps. If you're talking HT extensions, that is another story and doesn't have anything to do with the number of cores in a package.

The answer for those applications is to scale out, in other words run more simultaneous UBE's or app logic so you can take advantage of the second, third and fourth cores. It used to be, you'd hit a wall with a single server and then you could buy another server. Being able to fit multiple cores into a single socket saves space and often reduces power utilization in your computer room or data center.

Whether or not a single process can multithread is of little consequence, I'd say absolutely zero, when you are debating the merits of "MULTI PROCESSOR SINGLE CORE" or "MULTI PROCESSOR DUAL CORE".

[ QUOTE ]

What I want to point out about "going dual core" is that you really won't have much choice in the future


[/ QUOTE ]
but in the future, each core in a dual core might be faster than the core in a single core.

Today, however, thats NOT what is going on. The fastest cores under a dual core processor is 40% slower than the fastest single core processor. Theres a lot of marketing hype from both sides (Intel and AMD) and they are driving the market to purchase multi-core processors as the "next new thing". As a consumer, I am always wary about what is in the marketplace, and processors have undergone a slump in my opinion in the past 3 years.

AMD is already working on quad-core processors - and it is likely that dual-core will be very rapidly overtaken. Remember, we just recently started seeing 64bit processors - which were never as fast as their 32bit counterparts from a clockspeed perspective - and since we're talking JDE world here (rather than 3D gaming world) - its important to decipher the marketing bumpfh from these horse-sellers in the marketplace that consumers are trying to understand.

The future can change rapidly. Just because one manufacturer tells you that "this is the future" - its important not to subscribe to that fact without investigating it yourself. I've run benchmarks of SP23 against both single-core and dual-core processor machines at the same price. The single-core machines are faster than the dual-core machines.

[ QUOTE ]
I would EXPECT the UBE's to run the same callobjects as any other written application however

[/ QUOTE ]

UBEs never have run BSFNs in callobjects in a standard configuration -- in fact, that would degrade performance even more, as the ube would have to send net messages to a callobj and wait for a response for every single BSFN call (and there can be billions of calls in an intensive batch), since the business logic for a single client( batch or interactive user) isn't written in a multi-threaded fashion.

The reason callobj kernel threads make more sense is that they service multiple users, however, each user still is only getting one thread. Think of a single ube as a single user and you see why this makes sense. UBEs run all BSFNs in process, unless you've done some OCM jiggery-pokery, and when they all run in process, the ube processes MUCH faster than it could by talking to callobj kernels.

This is exactly right.