On Thursday 22 March 2007 17:45, Peter wrote: > On Thu, 22 Mar 2007, Tzahi Fadida wrote: > > On Thursday 22 March 2007 16:18, Peter wrote: > >> On Thu, 22 Mar 2007, Tzahi Fadida wrote: > >>> Advocating is a strong word, i was suggesting. How exactly would you > >>> address 128gb,256gb? Unless of course your system board and CPU > >>> supports such sizes... > >> > >> The board does not care about sizes. Disk requests are serialized and > >> they can be any lengths. Implementing a 1024 bit wide address counter to > >> be pushed out serially to hardware is trivial even with an 8 bit cpu > >> from 20 years ago. The problem is speed and size. Anything that fits in > > > > And where prey tell, you can go to a store today and get a computer that > > support addressing of 1024 bits RAM? > > Wht are you assuming that the computer needs to be able to address 1024 > bits of RAM if the address counter is made that wide (in software). You > can easily map this 1024 bit address space so one part covers actual > ram, another the video ram, another is mapped to a network drive, > another ... it's called virtual memory, and it does not say anywhere > that it is limited to one level. Of course this costs time. But ...
Listen, i did not suggest to map 1024 bits, i was using your example. What you are talking about is PCI and other buses. On the same 32bit address bus you can address many data buses using bridges, which is exactly what i said from the beginning and yes, as muli said earlier, it is slow. > > > Being realistic, you have a 32bit system in place and all you need is to > > implement the 2 or 4 gb blooming filter, why buy an insanely expansive > > new computer instead of just adding some PCI with some memory that would > > be good enough for your needs? Like an Asus battery backed ram drive in > > 50$ + as much ddrs you need. I think 1gb~=500nis *4 = 2000. ANS + 50$ = > > 2250nis. > > Because you don't need a Blooming filter 4GB in size. You need one > Blooming filter 500MB in size, two 256MB, four 128MB, and the last two > fit into the second 800NIS PC (the first 500MB fits into the first). > Anyway the B. filter is not good for storing data but it could be good > to check f.ex. hash keys present/absent in a cache quickly and cheaply. That was not the initial argument i brought. If you only need 128mb then there is no problem. I was talking about 2^32 potential entries. If i understand correctly, the wider the key the less false positives there are. Everything comes at a cost. > > The idea is that there is no canned solution. There is hard work to be > done to make something support 30E6 records in real time. A Bloom filter > may be a part of it. Maybe not. But SQL is almost certainly a part of > the problem and not of the solution ... again I'm not an expert here. SQL is not a problem, it is a generic solution. Obviously a specific solution will always be better than SQL. SQL provides you with a quick, generic way to store and retrieve data using relational algebra. If you know in advance that throughout the application life you will only need a hash table then there is no need to use SQL. Mitigating the generic solution is the RDBMS, which provides past the obvious retrieval and execution mechanisms, query optimizers, planners, etc... to get you as near as possible to the specific solution. -- Regards, Tzahi. -- Tzahi Fadida Blog: http://tzahi.blogsite.org | Home Site: http://tzahi.webhop.info WARNING TO SPAMMERS: see at http://members.lycos.co.uk/my2nis/spamwarning.html ================================================================To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
