[Home] [Groups] - Message: [Prev in Group] [Next in Group]
10209: Re: [MUD-Dev] Noise: boys will be boys (was Re: [MUD-Dev] Multi-threaded mud server.)
[Full Header] [Plain Text]
From: Chris Gray <cg@ami-cg.GraySage.Edmonton.AB.CA>
Newsgroups: nu.kanga.list.mud-dev
Date: Wed, 19 May 1999 22:30:36 -0600
Organization: Kanga.Nu
[Ola Fosheim:]
> ohshudupmineis100mhzandincrediblyfastandiamnotgoingtobuyanewoneunlessitistentimesfasterandhalfthepricecanihaveyoursplease?
<laff!> <Sticks tongue out and goes "THHBBBBRRTT!"> No! :-)
> Only 1000??? Hardly impressive for a man at your age!!! Even *I*, a snotty
> twentysomething, can beat that! My CBM64 is probably 1200 times slower than
> my P100 is ((32bit/8bit)*(3cycles/1cycle)*100), and that is for simple
> integers. If we are talking floatpoint, expect to see numbers approaching
> 100000. Not to mention that it takes two minutes for this multiprocessor
> machinegun to load 64kb or so from a diskdrive, for cassette it would be...
> forget it.
Hmm. I wouldn't count all of the 32/8, but I had forgotten the multiple
cyles. I was going from my old 500khz 8080, to 300Mhz.
> Chris, you really need to understand that your dream will probably take
> another 10 years or so to implement, and by that time we probably have a new
> programming paradigm, a new architecture, computers will be 1000 times
> faster than now, free muds are better than the commercial muds of today and
> you will have to rewrite your server in a new multiprocessing language
> anyway.
Gack! That's all one sentence. I hope I'm not that far away (if only I
would put some time in on it). Also, as I've mentioned in the past, I
think I can readily absorb as much resources as can be thrown at me. As
for new programming paradigm's, I certainly haven't adopted the current
(and starting to fade - hurray!) C++ stuff. Us old curmudgeon's resist
that sort of thing.
> Seriously, I am wondering if understanding how the processor pipeline works,
> caching etc, etc, is getting in the way when I use languages like C and C++
> where I _know_ how this will look as machinecode, and what the consequences
> are.
Agreed. I prefer to not have to think at that level. I've never really
been into performance analysis, but I do find it hard to put up with
code that I know can easily be done significantly more efficiently.
--
Don't design inefficiency in - it'll happen in the implementation.
Chris Gray cg@ami-cg.GraySage.Edmonton.AB.CA
http://www.GraySage.Edmonton.AB.CA/cg/
_______________________________________________
MUD-Dev maillist - MUD-Dev@kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev