Author: Dann Corbit
Date: 13:04:50 12/17/04
Go up one level in this thread
On December 17, 2004 at 10:02:37, Vincent Lejeune wrote: >On December 17, 2004 at 04:39:41, Dann Corbit wrote: > >>On December 17, 2004 at 03:36:51, Vincent Lejeune wrote: >> >>>On December 17, 2004 at 02:37:32, Vincent Lejeune wrote: >>> >>>>On December 16, 2004 at 23:20:34, Paul Byrne wrote: >>>> >>>>>On December 16, 2004 at 22:23:49, Dann Corbit wrote: >>>>> >>>>>>On December 16, 2004 at 20:56:56, Robert Hyatt wrote: >>>>>> >>>>>>>On December 16, 2004 at 18:25:42, Vincent Lejeune wrote: >>>>>>> >>>>>>>>On December 16, 2004 at 17:31:10, Scott Gasch wrote: >>>>>>>> >>>>>>>>>On December 16, 2004 at 14:46:33, Dann Corbit wrote: >>>>>>>>> >>>>>>>>>>On December 16, 2004 at 03:37:46, Gian-Carlo Pascutto wrote: >>>>>>>>>> >>>>>>>>>>>On December 15, 2004 at 22:24:49, Alex wrote: >>>>>>>>>>> >>>>>>>>>>>>Of course it would be foolish to buy a New computer now...... Micrsoft is going >>>>>>>>>>>>to present a 64 bit OS nest year, the Christmas prices of new computers will >>>>>>>>>>>>drop like a BRICK by Jan 1.......... But ! Let us speculate.... Hmmmmmmmmmm >>>>>>>>>>>>What will 64 bit DO for chesss programs ....Yes yes I KNOW AMD has New processor >>>>>>>>>>>>that does 64 bit..... but what is the difference ..reallY? D >>>>>>>>>>> >>>>>>>>>>>Speed. >>>>>>>>>>> >>>>>>>>>>>You can expect programs to get 10-60% faster from 64 bit mode. >>>>>>>>>>> >>>>>>>>>>>This is in addition to the Athlon64 already being so fast in 32 bit mode. >>>>>>>>>> >>>>>>>>>>Another potential advantage is the large address space. >>>>>>>>>> >>>>>>>>>>With terabytes of ram directly addressable, potentially totally new solution >>>>>>>>>>ideas may be formulated. >>>>>>>>>> >>>>>>>>>>For instance, you could memory map the 3-4-5 man tablebase files and lose the >>>>>>>>>>disk access penalty. That might make them give a large Elo boost, while the >>>>>>>>>>disk access method for 32 bit systems seems to be about break even. >>>>>>>>>> >>>>>>>>>>You could have 20 GB hash tables. >>>>>>>>>> >>>>>>>>>>You could store (in ram) a large tree of every chess game ever played together >>>>>>>>>>with statistical information on each node. >>>>>>>>> >>>>>>>>>...of course this all assumes you have a machine with 20Gb of physical memory >>>>>>>>>and a chipset that supports that much RAM. Until the cost of memory comes way >>>>>>>>>down, you won't see me mapping EGTB files (compressed or not) into memory. :) >>>>>>>>> >>>>>>>>>Scott >>>>>>>> >>>>>>>>I'd suggest 2 pen drive USB like this : >>>>>>>>http://www.supermediastore.com/pendrive-4gb-flash-drive.html >>>>>>>> >>>>>>>>Yes, no that cheap, but all 3-4-5 egtb way faster than disk >>>>>>> >>>>>>> >>>>>>>"faster than disk"? What kind of disk do you use for your egtb's? Floppy or >>>>>>>CDRom? :) The think you gave a link to is horribly slow compared to anything >>>>>>>except for CD/floppy drives... >>>>>> >>>>>>480Mbps seems pretty fast to me. >>>>>>What kind of disks are you using? >>>>>>;-) >>>>> >>>>>They lie. :) I think 480 Mpbs is the limit for usb 2.0; nothing to do with >>>>>the actual speed... they mention 7 Mbps on that page. Maybe 3 ms to read a >>>>>tablebase block? I looked a while back with a similar idea, the latency >>>>>of those things was a millisecond or two also. So it *might* be a little faster >>>>>than a hard drive, but if it is, it won't be by a huge amount... >>>>>-paul >>>> >>>> >>>>read: 7000KByte/s >>>>and access time is very low compare to disk ! >>> >>>and if you want better performance than USB go for ATA : >>>http://www.memtech.com/35inch.html >> >>While 26 MB/sec read throughput sounds fairly impressive: >> >>2 to 60 Gbyte capacity >>16 Gbytes under 16mm >>Full -40°C to +85°C industrial temperature >>Low-profile 3.5" drive form-factor >>Unitized 40 pin IDE and 4-pin power shrouded header >>96-bit ECC for exceptional data reliability >>5-volt, low power operation >>2000G operating shock >>20G operating vibration >>16 Mbyte Cache >>26 Mbyte/sec Read throughput >>20 Mbytes/sec Write throughput >>10 year data integrity >> >> >> The AT3550 Wolverine solid-state flash drive is a UDMA-66 compliant IDE memory >>module offered in an extremely low profile 3.5 inch drive form-factor. The >>primary storage media within the drive is sector erasable NAND EEPROMs (Flash >>Memory). Using these devices, Memtech is able to deliver up to 60 Gbytes of >>uncompressed, nonvolatile solid state storage in an extremely small, rugged >>form-factor. The access time for the drive is under 0.1 milliseconds, which >>permits thousands of transactions to occur per second. Sporting a UDMA-66 >>compliant interface with a 66 Mbyte/sec burst data rate, cached read data rates >>are 26 Mbytes/second, with cached writes going at 20 Mbytes/second. An >>integrated holdup circuit guarantees data integrity under brownout or power-fail >>conditions. >> >>It's nearly 3-4 times slower than 15K U320 SCSI: >>http://www.storagereview.com/php/benchmark/compare_rtg_2001.php?typeID=10&testbedID=3&osID=4&raidconfigID=1&numDrives=1&devID_0=279&devID_1=277&devID_2=272&devID_3=273&devCnt=4 > >It's nearly 55 times faster than 15K U320 SCSI: > >5.5 ms to 0.1 ms access time The seek time is impressive, but I wonder why the transfer rate lags so badly (in comparison). It's probably the interface specification. If they did the same technology and used U320 controller, maybe they could create something stunning. At any rate, it looks like a poor idea to me unless your machine is already maxed out in memory. If you just add ram to your computer (which is cheaper anyway) then you get the memory access speed for access time (what's that -- 70 ns or so?). However, if your machine has a max of (say) 4GB of ram and it is full and you have some tasks that seek tiny little bits of things like a madman, it might be a good idea. >>Between 97.4 MB/sec and 74.4 MB/sec for Maxtor Atlas 15K II (147 GB Ultra320 >>SCSI), depending on the platter position during the write.
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.