[MUD-Dev] Noise: boys will be boys (was Re: [MUD-Dev] Multi-threaded mud server.)

[Chris Gray]

[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 at ami-cg.GraySage.Edmonton.AB.CA
               http://www.GraySage.Edmonton.AB.CA/cg/


_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev