Date: Mon, 30 Apr 2001 23:52:04 -0600 From: Wes Peters <wes@softweyr.com> To: "Michael C . Wu" <keichii@peorth.iteration.net> Cc: Remy Nonnenmacher <remy@boostworks.com>, keichii@iteration.net, ajh3@chmod.ath.cx, jgowdy@home.com, freebsd-hackers@FreeBSD.ORG Subject: Re: x86-64 Hammer and IA64 Itainium Message-ID: <3AEE4F04.B1CDDAE8@softweyr.com> References: <20010426180836.C88522@peorth.iteration.net> <200104271108.f3RB81C63528@luxren2.boostworks.com> <20010427104703.G88522@peorth.iteration.net>
next in thread | previous in thread | raw e-mail | index | archive | help
"Michael C . Wu" wrote:
>
> ....
> You've just ruined any real reason for me to continue my education
> as a computer architecture student.... :P
> "Let all the computer scientists design the CPU and hope that
> they take into account the electromagnetic effects!!"
Er, turn this around to: design the system so the software will actually
run quickly on it. This was the design goal of RISC, and it moved a
giant leap towards that goal, as long as memory was as fast as the
processor. Now that processors outpace their memory subsystems by
many times, it's probably time to start going the other direction
again. This time hopefully we'll do it intelligently. There's your
reason for sticking around.
> | Now imagine you get a fully programmable add-on card. If something get
> | wrong, the device driver writer can fix it and not just put hacks to
> | handle this or this revision of a chip. Even further, computation part
> | of the DD can be pushed onto the card. Imagine a NIC pushing you mbufs,
> | pcb entries, etc... You will also not have to wait for the good willing
> | of XYZ company to release documentation or seeing a version of a chip
> | being phased out in favor of the new super-one released only with an
> | opaque Windows driver.
>
> Can you picture the difficulty of writing drivers for these
> devices that do so many specific things? I am sure Bill Paul,
> Mike Smith, et al. will be so thrilled to read thousands of pages
> of documentation to write one driver.....
> Engineering is about K.I.S.S., not making it very complicated for
> everyone involved.
Snort. You should look inside a layer 3 (or higher) switch. Queueing
engines with 16K - 64K queues, multiple queues per port, with programmable
priorities per-queue/per-port, programmable thresholds per queue, auto-
magic buffer management, etc., etc., all in the hardware.
If you think that's exotic, wait'll the next generation of hardware
firewalls enters the field. That'll be a heyday.
Engineering: building something that customers want to buy, that can be
produced profitably.
--
"Where am I, and what am I doing in this handbasket?"
Wes Peters Softweyr LLC
wes@softweyr.com http://softweyr.com/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3AEE4F04.B1CDDAE8>