Author: Vincent Diepeveen
Date: 16:08:15 08/03/03
Go up one level in this thread
On August 03, 2003 at 16:52:17, Eugene Nalimov wrote:
>Sorry, I'll be clearer this time:
>
>(Talking about claim that Windows kernel is written in the assembler)
>
>SARCASM ON:
>
>This is definitely so, especially if you take into account that NT/2k/XP
>variants were commercially sold not only for x86, but for PowerPC, MIPS, Alpha,
>and IA-64 CPUs. Of course MS wrote 5 kernels in the different assembler
>languages...
>
>SARCASM OFF.
>
>Vincent is the only source from which I hear that fact. And if I have to choose
>between Vincent's words and NT source code on one of my developer's machine,
>I'll trust the later...
So there is a C version too. Cool to know.
But for your notice, yes the released thing has major assembly parts in the
kernel. Of course you don't know what the other divisions of microsoft are
doing. I guess you are in the compiler division?
I know that most people do not count inline assembly (johan de koning) as being
assembly, but call it 'C code' even when it is the important part of the
software that is in assembly. If you belong to that gang just raise a hand.
>Thanks,
>Eugene
>
>Thanks,
>Eugene
>
>
>On August 03, 2003 at 15:22:19, Vincent Diepeveen wrote:
>
>>On August 03, 2003 at 14:49:12, Eugene Nalimov wrote:
>>
>>>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.
>>>
>>>This is definitely so, especially if you take into account that NT/2k/XP
>>>variants were commercially sold not only for x86, but for PowerPC, MIPS, Alpha,
>>>and IA-64 CPUs. Of course MS wrote 5 kernels in the different assembler
>>>languages...
>>
>>It is hard for me to understand why so much is in assembler and why there
>>seemingly is no x bits 'C' version which they can compile on any hardware with
>>little effort.
>>
>>All you need then is a good compiler and perhaps just a bit of handtuning here
>>and there.
>>
>>Even a way slower C version of such an OS would kick of course incredible butt
>>already for the different testsets. Now and in the future.
>>
>>In the meantime what i'm using is:
>>
>>bash-2.05$ uname -a
>>Linux a1.teras.sara.nl 2.4.20-sgi220r3 #1 SMP Wed Jun 4 16:43:37 PDT 2003 ia64
>>unknown
>>
>>bash-2.05$ cat /proc/sys/kernel/shmmax
>>90387103744
>>
>>This REMINDS me of a problem i have with windows. In order to get for different
>>processes pointers in shared memory at the same virtual adress space i use next:
>>
>> TreeFileMap = OpenFileMapping(FILE_MAP_ALL_ACCESS,FALSE,
>> "DiepMapFile_Tree");
>> if( TreeFileMap == NULL )
>> mprint("Fatal Error Mapping File: 'tree' for proces %i\n",
>> ProcessNumber);
>> tree = (TreeInfo *)MapViewOfFileEx(TreeFileMap,
>> FILE_MAP_ALL_ACCESS,0,0,0,(LPVOID)0x01000000);
>>
>>and of course createfilemapping to create it. The problem is that last parameter
>>in mapviewoffileex. I put it hardcoded at a certain adress in the memory. What i
>>fear is that some software like the JRE and some databases (oracle?) are using
>>similar adresses to map stuff into the same adress space.
>>
>>If they take my adress then i have bad luck simply.
>>
>>In Linux/IRIX/UNIX there is a way around that because i use ftok to get an
>>unique Key not yet in use by other software. Then shmget/shmat puts
>>automatically the allocated memory in the same adress space for the processes.
>>
>>Any way to prevent other processes taking care diep can't start parallel?
>>
>>>Thanks,
>>>Eugene
>>>
>>>>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.
>>>>
>>>>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.01 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.