So you consider it easier to change perfectly running code (for what reason?) instead of fixing the compiler settings?
Sometimes, yes. The project was for a medical application, with 99% of the code written by others. I'm not going to change global compiler settings and risk exposing some optimization error, when I can simply change a few lines of my code.
In the general case, if you convert a recursive program to non-recursive, you also need to save the current state, including something equivalent to an instruction pointer if there are multiple places in your routine where you want to go a level deeper. In addition, you may need a dispatcher to go back to that point when you come back. Using a function call + return may even be faster in those cases because you're using the native support, and you don't need to waste another register on a user stack painter. Also, maintaining your own stack requires additional memory. If you put this on the heap, you also have the overhead of malloc/free.
if you screw up it can be very bad. It can be much worse than, say, an infinite loop.
I'd rather have very bad effects in my embedded code than small and subtle effects that can stay hidden for a long time, but still have the potential to screw up the application.
C++ RAII eliminates most of the need for local gotos though - you can make local classes with destructors for cleanup, with the added benefit that it's exception-safe.
But I wouldn't want throw exceptions in a linux kernel function. It introduces too many things going on behind the curtains that may not be safe in a particular situation.
Because you don't know always for sure that your compiler implements tail recursion optimization. I've worked on embedded projects, where the whole project was compiled with -O1 and tail recursion wasn't optimized. So, if the iterative solution isn't any more complex, I'd use that instead.
First of all, there's no need to go back to 1917 sea levels. If we can avoid sea levels going higher than 2050 levels, most people will be okay. Secondly, the standard of living isn't tied to the amount of CO2 produced. There are other ways, including nuclear, of producing the same amount of energy without CO2. So fuck off with your assumptions. Finally, when fossil fuels run out, you're going to have to switch anyway, so according to your stupid logic we'd have to go back to 1917 standard of living then.
Embedded people avoid recursion like the plague because they have limited resources.
You can't make blanket statements like that. It all depends on the recursion depth, your embedded platform, and the requirements of an alternative solution. You can have embedded platforms with 100 bytes or with 100 MB, with or without virtual memory and possible dynamically growing stacks. Also, if you need to build your own stack to avoid recursion, where are you going to store it ? Static memory is wasteful, and not all embedded platforms have heaps. And what are you going to do when your manual stack isn't big enough ?
Sometimes desktop guys use it, and it works okay until someone opens a big file and it needs 18GB of RAM
Tail call optimization only works if you're actually doing a tail call, which isn't always the case. And if you're always doing a tail call, the recursion can be replaced by an iteration without too much trouble.
The problem with microkernels is not the wrapping and unwrapping of calls, or the cost of switching, or copying memory. The real problem is that different tasks in the microkernel do not have a synchronized view of the system state. As soon as you pass a message where you copy parts of the state, you have two different copies of that state, and as one task changes their copy, the other becomes outdated. Managing all of this becomes more complex than having a big kernel where different tasks share the same memory structures.
Sometimes recursion is appropriate, e.g. when walking binary trees, and a non-recursive solution requires just as much space to keep track of what you're doing. On big platforms with virtual memory, the stack will grow with as needed. On small platforms, the recursion doesn't need to go as deep.
The Government said the target would require domestic emissions to be cut by at least 85 per cent and the remaining emissions would be offset by planting trees or by sustainable investments abroad.
because sea level rise has been constant for hundreds of years and storms occur, naturally
Sea level rise has sharply accelerated in past 100 years compared to the centuries before that. This means that sea defences have be build higher on an accelerated pace too. And even if the height of your defences keeps up with the rising waters, the cost of an occasional breach will rise quicker.
http://www.realclimate.org/ima...
Slashdot Mirror
What vegetables have the most vitamin B12 ?
So you consider it easier to change perfectly running code (for what reason?) instead of fixing the compiler settings?
Sometimes, yes. The project was for a medical application, with 99% of the code written by others. I'm not going to change global compiler settings and risk exposing some optimization error, when I can simply change a few lines of my code.
In the general case, if you convert a recursive program to non-recursive, you also need to save the current state, including something equivalent to an instruction pointer if there are multiple places in your routine where you want to go a level deeper. In addition, you may need a dispatcher to go back to that point when you come back. Using a function call + return may even be faster in those cases because you're using the native support, and you don't need to waste another register on a user stack painter. Also, maintaining your own stack requires additional memory. If you put this on the heap, you also have the overhead of malloc/free.
if you screw up it can be very bad. It can be much worse than, say, an infinite loop.
I'd rather have very bad effects in my embedded code than small and subtle effects that can stay hidden for a long time, but still have the potential to screw up the application.
Maybe the tree is on an SD card, and the stack resides in a small RAM.
It's not inefficient if the compiler optimizes it away.
Goto: A way to enable lousy programmers to write impenetrable code
I don't let lousy programmers touch my code. Problem solved.
Production needs resources, and resources are limited. So, it's natural that a competition for those resources develops.
C++ RAII eliminates most of the need for local gotos though - you can make local classes with destructors for cleanup, with the added benefit that it's exception-safe.
But I wouldn't want throw exceptions in a linux kernel function. It introduces too many things going on behind the curtains that may not be safe in a particular situation.
There are languages that do not optimise tail-recursion, such as C
A good C compiler will do tail recursion.
Yeah ... but why would anyone do that?
Because you don't know always for sure that your compiler implements tail recursion optimization. I've worked on embedded projects, where the whole project was compiled with -O1 and tail recursion wasn't optimized. So, if the iterative solution isn't any more complex, I'd use that instead.
Not only faster, they are also simpler to get right, for everything except trivial cases.
First of all, there's no need to go back to 1917 sea levels. If we can avoid sea levels going higher than 2050 levels, most people will be okay. Secondly, the standard of living isn't tied to the amount of CO2 produced. There are other ways, including nuclear, of producing the same amount of energy without CO2. So fuck off with your assumptions. Finally, when fossil fuels run out, you're going to have to switch anyway, so according to your stupid logic we'd have to go back to 1917 standard of living then.
Embedded people avoid recursion like the plague because they have limited resources.
You can't make blanket statements like that. It all depends on the recursion depth, your embedded platform, and the requirements of an alternative solution. You can have embedded platforms with 100 bytes or with 100 MB, with or without virtual memory and possible dynamically growing stacks. Also, if you need to build your own stack to avoid recursion, where are you going to store it ? Static memory is wasteful, and not all embedded platforms have heaps. And what are you going to do when your manual stack isn't big enough ?
Sometimes desktop guys use it, and it works okay until someone opens a big file and it needs 18GB of RAM
Never heard of paging ?
Tail call optimization only works if you're actually doing a tail call, which isn't always the case. And if you're always doing a tail call, the recursion can be replaced by an iteration without too much trouble.
The problem with microkernels is not the wrapping and unwrapping of calls, or the cost of switching, or copying memory. The real problem is that different tasks in the microkernel do not have a synchronized view of the system state. As soon as you pass a message where you copy parts of the state, you have two different copies of that state, and as one task changes their copy, the other becomes outdated. Managing all of this becomes more complex than having a big kernel where different tasks share the same memory structures.
2) It's possible to write any traversal algorithm using loops, without any recursion.
Sure, but if that requires building your own stack, you haven't really gained anything.
Sometimes recursion is appropriate, e.g. when walking binary trees, and a non-recursive solution requires just as much space to keep track of what you're doing. On big platforms with virtual memory, the stack will grow with as needed. On small platforms, the recursion doesn't need to go as deep.
That would require the immigrants to actually care for our old people. That would be an interesting concept.
It may have been different, but it was still balanced.
How will you run your diesel trucks and buses when oil runs out ?
No, I'm not saying that. Try reading a bit slower.
The Government said the target would require domestic emissions to be cut by at least 85 per cent and the remaining emissions would be offset by planting trees or by sustainable investments abroad.
Nobody uses Dropbox, though.
because sea level rise has been constant for hundreds of years and storms occur, naturally
Sea level rise has sharply accelerated in past 100 years compared to the centuries before that. This means that sea defences have be build higher on an accelerated pace too. And even if the height of your defences keeps up with the rising waters, the cost of an occasional breach will rise quicker. http://www.realclimate.org/ima...