Author: Vincent Diepeveen
Date: 13:22:11 08/04/03
Go up one level in this thread
On August 04, 2003 at 11:12:16, Robert Hyatt wrote:
>On August 03, 2003 at 19:08:15, Vincent Diepeveen wrote:
>
>>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
>
>Your pompousness and ego never cease to amaze me.
>
>1. _all_ operating systems have _some_ assembly language in them. There
>is no way to do some things in C. Yes, inline assembly is possible, but it
>is _non-portable_ and it is not easy to read/write.
And it is very easy to figure out. Compiler generated assembly is a lot diff
from hand written assembly.
I am really amazed that initially it was denied that *any* source was assembly
where everyone knows the crucial routines, which is about whole of the kernel
that practically gives you services during the run of your software, is
assembly.
It is trivial that the majority of code which is drivers and other DLL stuff
doesn't need to be in assembly with a few exceptions (certain hardware drivers
are very crucial so they're in assembly)
>2. Suggesting that you know more than Eugene about the internals of Windows
>is so far beyond ridiculous, it takes light 3 years to get from ridiculous to
>you.
Eugene initially suggested that nothing at his machine is assembly. Now he's
already saying something quite different. I am sure you have not noticed that.
>_nobody_ writes an O/S in assembly today...
You keep forgetting a crucial aspect. *when* did the NT kernel in x86 started to
get created by microsoft?
Right at a time where hardware was very very slow and where assembly was the
only option. Without exception the commercial chess programs at the time were in
assembly back then: Hiarcs, Genius, Rebel, Quest, Kallisto, Schach (not
commercial though).
Same was of course true for the NT kernel. They just maintained it like that.
And it *is* fast. Let's face it.
If intel would write hardware processors only in a general language which is
portable, then AMD would be laughing for another 10 years.
Everything is manual. The interest is too big simply.
Only the big processors like itanium and such get sold so little that it doesn't
make sense writing special assembly kernel for it.
So if that longhorn stuff from Nalimov is meant for itanium2 i can very well
understand it doesn't have any assembly in it :)
>
>
>>>
>>>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 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.