Date: Fri, 27 Apr 2001 13:10:21 +0200 (CEST) From: Remy Nonnenmacher <remy@boostworks.com> To: keichii@peorth.iteration.net Cc: keichii@iteration.net, ajh3@chmod.ath.cx, jgowdy@home.com, freebsd-hackers@FreeBSD.ORG Subject: Re: x86-64 Hammer and IA64 Itainium Message-ID: <200104271108.f3RB81C63528@luxren2.boostworks.com> In-Reply-To: <20010426180836.C88522@peorth.iteration.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 26 Apr, Michael C . Wu wrote: > On Wed, Apr 18, 2001 at 04:24:18PM +0200, Remy Nonnenmacher scribbled: > | On 17 Apr, Andrew Hesford wrote: > | > On Tue, Apr 17, 2001 at 12:49:04PM -0700, Jeremiah Gowdy wrote: > | For sure. Look at how it's pretty more easy to use an ARM or MIPS core > | to handle gluelessly the PCI, SDRAM, Flash etc... and just add specific > | components for the analogic interface side. > > And what happens to the overhead of intercommunication between these > devices? :) > > ... > Infiniband > ... > PCI-X > > Btw, we already use ARM/MIPS stuff in many PCI applications... > NIC chipsets are essentially specialized processors. > Think about about the new Intel NIC's with i960 built-in > > | X86 (and -64) is going to be just die hard PC and workstations where > | deadly wrong past must be taken into account at the price of wasted > | power. Futur is more than probably Itanium and alike for servers CPUs > > And what's so deadly wrong about all the new features of Itanium > and KA-64? > I do not doubt that IA64 will be a great think. by 'x86' I meant the current Pentium architecture that embbed (and is slowed down by) tons of gates just to handle old 8086 binary compatibility. IA64 do not need to. > | and a bunch of ARMs for low-level I/O tasks. Back to imagination. (Take > | a look at 0.15um copper process FPGAs with embeded ARM at Altera, for > | example, and you will see why no one, in the futur, will never ever need > | a proprietary and undocumented 'server class' SCSI or network card). > > Please make Altera/Xilinx make their FPGA programming software > freely available. > I do not know about Xilinx but Altera does (to the extension that you get stuck with their components). Even evaluation boards are getting cheaper and cheaper. My point is that system software is getting close to it's maximum efficiency with existing hardware. Each performance step will require bigger and bigger rework of the whole code. In the mean time, either we sit down and wait for better CPUs or hope that a electronic design engineer read the code and start designing really helpfull devices (remember: Digital is dead!), either we (as software writers) start entering the programmable hardware world. Take a look at device drivers in the kernel. You will find a lot of pesting in the comments about this or that that require copying, zeroing, duplicating, aligning, etc... All this resulting in CPU correcting ill behaviors. 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. > | It would be really interesting to have a server-class FreeBSD SMPng > | version and, in conjonction, an highly portable and small Pico-bsd like > | one to animate the embeded processors. > > Please define "server-class" SMPng :) "An SMP version having a computational power curve as close as possible of the Y=X line, where X is the number of processors" (Note that it is easier (to some limits) as the number of process increases but is really difficult when not.) > You do realize that, in the embedded systems world, sometimes > we use SMP, right? For example, multiple DSP ASIC's in the same > router..... Hum... "Symetric" MP ? You sure ? ;). RN. IeM 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?200104271108.f3RB81C63528>