Author: Vincent Diepeveen
Date: 16:09:44 08/03/03
Go up one level in this thread
On August 03, 2003 at 16:56:26, Eugene Nalimov wrote: >On August 03, 2003 at 15:07:47, Vincent Diepeveen wrote: > >>Those pages June 2003, looks pretty new to me :) > >Yes, web site contains latest Platform SDK, dated June 2003. You can look >earlier PSDK, and trust me, those functions are there for some time... > >Thanks, >Eugene "The paper supports everything" quote from: Arturo I Ochoa, Caracas 2003 Thanks, Vincent >> >>>On August 03, 2003 at 11:12:15, Vincent Diepeveen wrote: >>> >>>>On August 03, 2003 at 06:14:06, Bo Persson wrote: >>>> >>>>>On August 02, 2003 at 18:22:58, Vincent Diepeveen wrote: >>>>> >>>>>>On August 02, 2003 at 09:15:26, Bo Persson wrote: >>>>>> >>>>>>>On August 01, 2003 at 14:13:18, Kim Roper Jensen wrote: >>>>>>> >>>>>>>>On August 01, 2003 at 14:00:18, Eugene Nalimov wrote: >>>>>>>> >>>>>>>>>I see quite different result on AMD64 when Crafty is compiled by 64-bit Visual >>>>>>>>>C. :-) >>>>>>>>> >>>>>>>>>Thanks, >>>>>>>>>Eugene >>>>>>>>> >>>>>>>> >>>>>>>>Sorry for asking but what did you see ?? :) >>>>>>> >>>>>>> >>>>>>>A non-disclosure agreement in his employment contract? :-) >>>>>>> >>>>>>>I'm sure we will see the numbers about 2 seconds after the compiler is released. >>>>>> >>>>>>Not really. What you need first is a windows version that can run the stuff 64 >>>>>>bits native at opteron. >>>>> >>>>>Yes, of course. Do you care to make a guess on what MS is using their Opteron >>>>>compiler for. :-) >>>> >>>>I guess they are working hard and basic problem is not only that m$ is 32 bits >>>>in some respects (file systems and such already long period ago 64 bits in 1995) >>>>but especially that their kernel stuff is written in assembly. >>>> >>>>That's one of the reasons why the kernel is much faster practically than linux >>>>for applications (if i put of old diep versions which aren't NUMA 2 processes to >>>>search at a single cpu machine then it runs *way* faster on NT, about factor 2 >>>>to 4 than under linux kernel). >>>> >>>>So using their own compiler for their own kernel is not exactly what they can >>>>do. >>>> >>>>A big challenge of opteron is that it is NUMA. >>> >>>That is not new challenge -- please go to MSDN web site and search for "NUMA". >>>You may be surprised. >>> >>>Thanks, >>>Eugene >>> >>>>I am sure m$ will be very happy supporting the AMD platforms. Competition in the >>>>hardware branche is good for microsoft. So in the highest levels of the >>>>organisations the x86-64 platforms will have a lot of support. >>>> >>>>Even if microsoft wouldn't want to support it, they still MUST support it >>>>because x86 is history within a few years and we all will be running x86-64 >>>>platforms only. Either with intel OR amd sticker. >>>> >>>>I guess even the biggest cpu amateurs will understand by now that intel is >>>>developing their own x86-64 processor generations. Perhaps even giving it a 'p4' >>>>sticker though it's an entirely new core. >>>> >>>>The only thing we do not know is *when* they will release their x86-64 cpu's. >>>>AMD simply has advantage there now. >>>> >>>>We can very shortly describe the x86-64 architecture. Cheap. High clockable and >>>>superior to everything out there including itanium. Especially superior to >>>>itanium. >>>> >>>>I'm running at a cpu or 64 now (itanium2-madison 1.3Ghz 3MB) and they are great >>>>for the highend but a joke even when compared to x86 for the average user. >>>> >>>>Intel plans to mass produce itaniums for the 'low-end' market have been put into >>>>the fridge a long while ago. The only reason intel is continuing this processor >>>>now (seemingly) is because they probably can't go back. Or perhaps they wait >>>>until they have x86-64 cpu's available. >>>> >>>>How can GCC 2.96 without profile recompilation be just 15% slower than intel c++ >>>>7.0 using profile information (prof_use) at the itanium platform? >>>> >>>>The problem of the itanium platform is they can't clock it high despite working >>>>for years already at that problem, it is too expensive, and it is impossible to >>>>write software for it. >>>> >>>>Even the current generations of supercomputers with itaniums that get delivered >>>>are missing major software support for it. Like crucial fortran libraries. >>>> >>>>This where > 60% of the total system time of supercomputers goes to gflops used >>>>by fortran libraries. >>>> >>>>If you add up the picture then it is a matter of time before the x86-64 will >>>>dominate everything. >>>> >>>>However it is sad to realize that most likely the linux world will be too late >>>>again. Despite that microsoft must convert their assembly libraries to new >>>>opteron assembly, we know they must be very far already with that conversion. >>>> >>>>This where the linux plans to write a NUMA kernel for kernel 2.6 have been just >>>>defined a few weeks ago. Not to mention the years it will take to carry out an >>>>effective implementation. >>>> >>>>For those who still do not understand what i'm talking about. When you have more >>>>than 1 opteron processor, so a dual opteron or even more processors, then it is >>>>of crucial importance that the kernel can run locally on each kernel for the >>>>jobs that can be done locally. >>>> >>>>Local memory at opteron is way faster than global memory. >>>> >>>>In fact the opteron asks for a cc-NUMA operating system which until recently was >>>>only getting used by very big non-real time supercomputer systems. >>>> >>>>I would not be surprised if microsoft is years sooner in releasing a version >>>>that works well than the linux community, despite that everyone will understand >>>>that bugfixing assembly code is a lot harder than fixing a bit of C code. >>>> >>>>Best regards, >>>>Vincent >>>> >>>>> >>>>>Bo Persson >>>>>bop2@telia.com
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.