Author: Robert Hyatt
Date: 18:36:52 08/04/03
Go up one level in this thread
On August 04, 2003 at 16:22:11, Vincent Diepeveen wrote:
>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.
Who "denied" this? Not Eugene. The kernel is _not_ "mainly assembly". It
is probably just like every _other_ O/S/ kernel, mostly C/C++ with a little
assembly thrown in where needed, say to fiddle with interrupts, or virtual
memory mapping, or whatever else there is that C has no clue about doing.
The "whole of the kernel" is _not_ assembly.
Regardless of what you keep saying.
>
>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.
>
He is saying the _same_ thing he said to start with. _most_ of the kernel
is in C/C++. You said "most of the kernel is in assembly". I know who _I_
believe. The man with the source in his hand, not the man with his brain
disconnected from his mouth.
>>_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?
Who cares? Unix has been around since 1970. _it_ was written in C, with a
very little assembly to go along with it. VMS for the vax was the same. As
was every other O/S of the era, all the way to current windows and linux
kernels.
>
>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).
So what?
>
>Same was of course true for the NT kernel. They just maintained it like that.
>
>And it *is* fast. Let's face it.
and it *is* C/C++. Face that too...
>
>If intel would write hardware processors only in a general language which is
>portable, then AMD would be laughing for another 10 years.
What is a "hardware processor"???
>
>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.