|
|
 Up |
|
  |
Author: CriCriCriCri Date: Aug 26, 2008 11:00
Igor Tandetnik a écrit :
>
> You said earlier:
>
> "But if I knew _beforehand_ that there wasn't enough memory
> available...
Immediately before each call to malloc()...
> Suppose you know "beforehand" how much memory is available. But how
> precisely does it help if you don't know how much you need? What do
> you mean by "enough", then?
Enough for each instance of the function.
I could stop recursing (efficient) and switch to another algorithm (less
efficient but possible to continue with less memory usage and thereby
complete the run).
Regards
|
| Show full article (0.75Kb) |
|
| | 87 Comments |
|
|
Author: SvenCSvenC Date: Aug 26, 2008 11:31
Hi CriCri,
>> Suppose you know "beforehand" how much memory is available. But how
>> precisely does it help if you don't know how much you need? What do
>> you mean by "enough", then?
>
> Enough for each instance of the function.
>
> I could stop recursing (efficient) and switch to another algorithm
> (less efficient but possible to continue with less memory usage and
> thereby complete the run).
Define what makes your recursion more efficient than another
implementation technique? I guess you mean more easy to implement.
If you transform your recursion algorithm to an iterating algorithm
you will have the same problem, you cannot know how many
iterations (with an allocation per iteration) you will need just like
now you don't know how deep your recursion will go.
If you have excessively deep recursions it will be more likely
the default stack spave of 1MB which will bite you.
|
| Show full article (0.91Kb) |
|
| | no comments |
|
|
Author: Alessandro VerganiAlessandro Vergani Date: Aug 26, 2008 12:04
"CriCri" leTIRETmaquis.net> wrote in message
news:48b3c61d$0$874$ba4acef3@news.orange.fr...>> "But if I knew _beforehand_ that there wasn't enough memory available...
>
> Immediately before each call to malloc()...
So why don't you check the return value of malloc?
--
Alessandro
|
| |
| no comments |
|
|
Author: CriCriCriCri Date: Aug 26, 2008 12:44
Hello Sven
SvenC a écrit :
>
> Define what makes your recursion more efficient than another
> implementation technique? I guess you mean more easy to implement.
Well I'm walking a B+ tree whose structure and size I never know in
advance. Nor do I know where I will need to go, because it depends on
the data the user requests.
A recursive algorithm is the natural choice (and certainly easy to
implement, as you say).
It seems to me that an iterative algorithm would add a considerable
overhead in exploring at each stage to decide what needed to be iterated!
> If you transform your recursion algorithm to an iterating algorithm
> you will have the same problem, you cannot know how many iterations
> (with an allocation per iteration) you will need...
Yes, I agree.
> just like now you don't know how deep your recursion will go.
|
| Show full article (1.65Kb) |
| no comments |
|
|
Author: CriCriCriCri Date: Aug 26, 2008 12:59
Hello
Alessandro Vergani a écrit :
>
> So why don't you check the return value of malloc?
Of course I check the return value of malloc() - and as it was before,
if I didn't get a certain block of memory the program had to exit.
As I explained to Scott, I need two blocks of memory each time.
So if I get the first and use it, then fail to get the second it's too
late: I can't go backwards.
Now I request the total size of the two blocks in one call.
- if there isn't enough for both I switch to another routine.
- if there is enough, no problem: I share it between them.
Regards,
Christophe
--
bitwyse [PGP KeyID 0xA79C8F2C]
Les conseils - c'est ce qu'on demande quand on connaît déjà la réponse
mais aurait préféré ne pas la savoir.
http://www.le-maquis.net
|
| |
| 1 Comment |
|
|
Author: SvenCSvenC Date: Aug 26, 2008 13:32
Hi CriCri,
> As I explained to Scott, I need two blocks of memory each time.
> So if I get the first and use it, then fail to get the second it's too
> late: I can't go backwards.
That information was the missing link to understand your
problem, I think.
> Now I request the total size of the two blocks in one call.
> - if there isn't enough for both I switch to another routine.
> - if there is enough, no problem: I share it between them.
So your problem is solved, isn't? Good to hear.
--
SvenC
|
| |
| no comments |
|
|
Author: Igor TandetnikIgor Tandetnik Date: Aug 26, 2008 14:06
"CriCri" leTIRETmaquis.net> wrote in message
news:48b3c61d$0$874$ba4acef3@news.orange.fr> Igor Tandetnik a
|
| |
| no comments |
|
|
Author: CriCriCriCri Date: Aug 26, 2008 18:55
Hello Sven
SvenC a écrit :
>
> That information was the missing link to understand your problem, I
> think.
Yes, I'm sorry I didn't explain clearly - I was trying to reduce it to
the minimum to keep it short.
> So your problem is solved, isn't?
Yes - and I think it's unbreakable.
Thanks to you all for your ideas and information.
There remains a question, though (raised by Igor and Alex) - see my last
response to the former below.
|
| Show full article (1.20Kb) |
| no comments |
|
|
Author: CriCriCriCri Date: Aug 26, 2008 18:38
Hello Igor
Igor Tandetnik a écrit :
>
> How are these two pieces of code substantially different?
That depends on the assumptions one makes.
- in the first case, as you pointed out youself, the process could be
pre-empted between the two library calls.
- they rely on malloc() and the (hypothetical) _memavl() returning
results for the same memory pool (see at the end for further details).
But in fact it hinges around what I failed to explain earlier (I was
trying to keep it short!):
--------
int wanted1, wanted2;
void *p1, *p2;
// program state 1
if ( ! ( p1 = malloc( wanted1 ) )
// switch to alternative method
// process first block
// --> program state 2
|
| Show full article (2.49Kb) |
| 1 Comment |
|
|
|
|
|
Author: Igor TandetnikIgor Tandetnik Date: Aug 26, 2008 19:38
CriCri leTIRETmaquis.net> wrote:> int wanted1, wanted2;
> void *p1, *p2;
>
> // program state 1
>
> if ( ! ( p1 = malloc( wanted1 ) )
> // switch to alternative method
>
> // process first block
> // --> program state 2
>
> if ( ! ( p2 = malloc( wanted2 ) )
> // handle failure - i.e. exit()
> // because it's no longer easy to switch to alternative method
>
> // process second block
Why not
|
| Show full article (2.27Kb) |
| no comments |
|
|
|
|
