> Hello!
>
> Seems, one guy guessed correct answer.
> He forgot to publish his brilliant ideas so that I'll make it.
Umm, I'll assume you're joking. His ideas don't sound so brilliant
to me.
>
> Alexey Kuznetsov.
>
>
> Forwarded message:
> > From galexand@sietch.bloomington.in.us Thu Feb 13 04:26:02 1997
> > Date: Wed, 12 Feb 1997 20:18:21 -0500 (EST)
> > From: Greg Alexander <galexand@sietch.bloomington.in.us>
> > To: "A.N.Kuznetsov" <kuznet@ms2.inr.ac.ru>
> > Subject: Re: CONUNDRUM.
> > In-Reply-To: <199702121746.UAA16330@ms2.inr.ac.ru>
> > Message-ID: <Pine.LNX.3.95.970212201603.27250E-100000@sietch.sietch.bloomington.in.us>
> > MIME-Version: 1.0
> > Content-Type: TEXT/PLAIN; charset=US-ASCII
> >
> > On Wed, 12 Feb 1997, A.N.Kuznetsov wrote:
> >
> > > The explanations sort of "It is cache problem" or
> > > "It is TLB trashing" are not accepted.
> >
> > You dumbass. I don't care if they are acceptable, but them's the limits of
Dumbass?
> > the hardware. A multi-tasking OS will be notably slower for some things
> > than a non-multi-tasking OS such as DOS or windows.
He's missing the point here: Windows *is* a multitasking operating system.
Even Windows 3.1 multitasks DOS applications *preemptively.* And you've
said that your program has the same results under Windows as it does under
DOS...
> >
> > > Bare MSDOS, Windows3.11 and Windows95 show the same (good) result.
> > >
> > > You can get the program sources, necessary data,
> > > and msdos binaries at ftp.inr.ac.ru:/CONUNDRUM.
> > >
> > > It prints lines sort of:
> > > Step 0 of 6400 45.917 0
> > > ^---------- Time measured by P5 CPU, normilized
> > > to seconds, supposing that CPU clock is 100MHz.
> > > So that, it is seconds only for 100MHz cpu.
> >
> > I'm fairly certain that your timing shit will not work under a 32-bit
> > prot-mode OS in the same way as it would under DOS. Use the time command
> > instead.
I don't think this is right, although I may be wrong. (Although Pentium
cycle-counters would also count all the overhead of the OS.) It may be
interesting, though, to see how much time the process was actually
scheduled for, using the times() syscall.
> >
> > > For MSDOS I see:
> > > Step 0 of 6400 39.376 0
> > >
> > > Do not ask me what this program does, and why
> > > 1.dg3 file is so huge. I have no idea.
> > > The only thing that I know is that binary codes
> > > really coincide.
> >
> > Then you know nothing and you are ignorant and have no right to state that
> > it is slower. Watcom files will not run under Linux. I don't care how much
> > they coincide.
Know nothing? Ignorant? I don't think so. If you had taken the time to
read his mail, you would realize that the Watcom code will run just fine,
since it's not doing any syscalls and just doing computations on memory.
He's disassembled the Watcom-produced code and assembled it again on
Linux.
> >
> > Greg Alexander
> > http://www.cia-g.com/~sietch/
> >
>
+-----------------------+---------------------------------------+
| Nathan Bryant | Unsolicited commercial e-mail WILL be |
| nathan@burgessinc.com | charged an $80/hr proofreading fee. |
+-----------------------+---------------------------------------+