Author: Christophe Theron
Date: 10:29:11 01/08/01
Go up one level in this thread
On January 07, 2001 at 22:39:49, Ian Osgood wrote:
>On January 05, 2001 at 18:31:11, Christophe Theron wrote:
>
>>On January 05, 2001 at 12:11:05, Ian Osgood wrote:
>>
>>>On January 04, 2001 at 12:07:27, Christophe Theron wrote:
>>>
>>>>On January 04, 2001 at 08:04:07, Tord Romstad wrote:
>>>>
>>>>>On January 03, 2001 at 12:26:00, Christophe Theron wrote:
>>>>>
>>>>>>On January 03, 2001 at 07:48:12, Tord Romstad wrote:
>>>>>>
>>>>>>>I apologise for the misunderstanding, I was reading too fast. However, I
>>>>>>>still think you are a little bit too optimistic. Mephisto Berlin did use
>>>>>>>transposition tables. If I understand correctly, transposition tables are
>>>>>>>difficult or impossible to implement in PalmOS.
>>>>>>>
>>>>>>>
>>>>>>>Tord
>>>>>>
>>>>>>Hash tables slow the program down a little bit under PalmOS (about 5%), but
>>>>>>there is no problem to implement them.
>>>>>
>>>>>OK. I should probably stop talking about things I have no first-hand
>>>>>knowledge about. I thought I had read somewhere that a PalmOS program
>>>>>could only allocate a relatively small amount of memory.
>>>>>
>>>>>Tord
>>>>
>>>>
>>>>
>>>>
>>>>You can allocate as much as you want, but in small chunks (max 64Kb). For hash
>>>>table management, having to deal with a large hash table split into small chunks
>>>>is not really a problem.
>>>>
>>>>
>>>>
>>>> Christophe
>>>
>>>Interesting... is this heap allocation (SDRAM) or storage allocation (Flash)? I
>>>was under the impression that current Palm devices had only small amounts of RAM
>>>for the running program storage and heap (<= 1MB) and that the advertised 8MB
>>>storage of a Palm device was all Flash memory. Flash memory is unsuitable for
>>>transposition tables because 1) it is slow and power hungry to write to, 2) you
>>>have to write (and maybe read) large blocks of data at a time, and 3) Flash
>>>memory wears out after too much writing (maybe a million writes the the same
>>>address?).
>>
>>
>>The program that is running has only access to a few Kb of RAM for its
>>data+stack+heap. That's the problem of the Palm, this amount is too small for
>>many applications.
>>
>>The rest of the memory is SDRAM, but it is controlled by the OS. You cannot
>>write directly into it, which is the reason why an app that crashes CANNOT
>>destroy other apps data. It can only destroy its own few Kb of data, but not
>>damage the rest.
>>
>>But you can allocate and read large chunks of memory. However you will have to
>>access it thru OS calls, which makes them slower to access of course.
>>
>>So a chess program using hash tables under PalmOS will be slowed down for this
>>reason. But depending on the philosophy of the program, it is maybe not a
>>serious problem.
>>
>>A program with a "high" NPS will definitely be handicapped by this problem
>>(maybe it is the reason why ChessGenius for Palm does not have hash tables). If
>>you can compute a position every millisecond and every hash table access takes
>>one millisecond and you have to access the hash table for every position, then
>>your program is going to be twice as slow!
>>
>>But if you can compute only one position every ten millisecond, then having to
>>wait one millisecond for a hash table access is only a 10% slowdown...
>>
>>
>> Christophe
>
>How about that... I have owned a Palm for over a year, yet assumed that it
>kept apps and databases in Flash ROM, like my other PDA, my trusty MessagePad
>2000. Thanks for the informative answer, Christophe.
So you don't use a Palm anymore? What a pity!
>Hmmm, you seemed to have gained quite a working knowledge of the internals of
>the Palm... have you been thinking of porting Tiger?
>
>Ian
I know how the Palm works and my program is written in C, so I guess I could
port Tiger to the Palm easily.
Christophe
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.