Author: Eugene Nalimov
Date: 13:52:17 08/03/03
Go up one level in this thread
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...
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.