Subject Re: Record Encoding
Author adem
--- 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

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.
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.

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.