--- Jim Starkey <jas@n...> wrote:

> Personally, I have little interest in producing software that runs
> on a PDP-11/20 or an IBM 360/30. A 360/75 had really cool lights,
> but was rather short on memory.

On behalf of everyone, I agree with this :-)

But, the thing is, and by the same token, I find it hard to
understand why you are so focused on some issues.

Disk and network throughput (I/O) is not a problem peculiar
to Firebird or Vulcan --it is a yin-yang thing for the whole
universe. Attempting to solve it in software on general-purpose
CPUs will only mean added load and latency to the system as
a whole.

It is, and will be, tackled by the hardware people; it is
their problem.

Just to sample what is available right now, here are a few
examples:

If it is the disk space and I/O you are worried you can buy
a hardware compression card for around $900 --it will get a
lot cheaper in time and when others enter into market.

http://www.aha.com/show_prod_type.php?id=7
AHA362-PCIX 3.0 Gbits/sec GZIP Compression/Decompression Accelerator

If it is the network throughput you're concerned, 10Gb/s is
around the corner. And, with 10Gb/s you have a problem that
has to be solved by specialized silicon: some sort of offloading
engine, or else the CPU will be monopolized by TCP alone.

There are various TCP offload engines (ToE) NICs that
does just that in HW.

http://www.alacritech.com/
http://www.qlogic.com/products/toe_products.asp
http://www.lewiz.com/magic2020.html
http://www.siliquent.com/products/index.html
http://www.microsoft.com/whdc/winhec/partners/intel05_IOAT.mspx

Intel, for one, will integrate these (called I/OAT) to server
MBs next year; I am sure AMD and others will not want to be
left behind.

Now, with regards to Firebird/Vulcan and databases in general:

Other than an article I seem to recall reading in the Byte
Magazine (from about the last quarter of the previous century)
--may it rest in piece-- mentioning a hardware database engine
being developed at University of Cambridge (UK), I am not
aware of a database-accelerator-on-silicon thing. Unless it
got classified and buried into Echelon, it was vaporware.

I have never heard of anything similar ever since. Which means,
to me, at least, there is no silicon solution for databases.

Which brings back to the point where I was wondering why you
focus on problems that are about to be solved for all, instead
of adding new features, data types, ACL type security etc.
that Firebird/Vulcan needs.

Just my 0.02 of some currency.

Cheers,
Adem