I heard that there is a story behind the increment operator ++: early CISC machines, such as a the PDP-11, had an "auto-increment" memory access scheme.
They had both post-increment and pre-decrement as well as deferred post-increment and deferred pre-decrement.
Even better was the Data General Nova. It had autoincrement and autodecrement locations in memory. Access one of those locations and the contents would be automatically incremented (or decremented) as part of the operation.
they could have written a license that gave other companies the right to reuse the code for non-commercial uses only, and that would have been a better compromise.
It would be unsafe if there was any possibility of the buffers needing to stay around very long. Like I said, I generally allocate 10x the maximum number I really think I'll need just to be safe. In general, my goal is performance, limiting heap fragmentation, or both.
I've never tried to use this where it wasn't appropriate -- i.e., where the buffer was needed for more than just a very short-term thing.
Of course, you couldn't use this in a multi-threaded program unless only one thread needed short term buffers. For a multi-threaded program, you would really need to have a separate allocation of buffers per thread or use a method of locking the buffers and not reallocating those buffers that are still locked.
What you are describing is for an entirely different type of problem.
What you are describing will require a search of the bitmap to locate an available buffer. It will also require that the program mark the buffers as available once they are no longer needed.
That is not at all what I was describing.
What I was describing was reusing buffers without needing to check whether or not they were being used by anything else because of the nature of the use of those buffers, i.e. by the very limited time the buffers would be used and by using the least recently used buffer, there is no need to check to see if they are being used because they would always be available.
And, of course, for that type of thing, LRU is pretty much required. I guess you could use the next to the least recently used buffer, but there wouldn't be any point of doing that.
In other words, the buffers are immediately available with no need to search for an available buffer. Just choose the next buffer (which is the least recently used).
My scheme also allows you to increase the buffer size if the available buffer size is too small.
In what I was describing, you would typically allocate N buffers with N mallocs. Then, when a buffer was too small, you just free that buffer and malloc it with a larger request.
By the way, I never claimed that a linked list structure was central. You could just as easily maintain an array of 100 pointers and an index into the array to find the location of the LRU buffer. It is O(1) either way.
The first time I ever did this, I allocated the N buffers with one malloc and had a flag bitmap that indicated whether or not each buffer was a buffer or a pointer to a larger buffer. Thus, in most cases, it performed one malloc and one free, did not require a search to find an available buffer, and temporary assignments were usually constant time.
What I described was to allocate a list of buffers and reuse them for very short termed uses without needing to check to see if what was using them before was finished with them.
In other words, you could conceivably have 1,000 or more functions sharing some fixed number of buffers (say 100 buffers) between them. When a function needs a buffer, it would just grab the least recently used buffer and reuse it.
The idea depends on the buffers being used for a short enough time that when you need a new buffer, whatever was using the least recently used buffer no longer has any need of it.
It's really a much different idea.
If you needed something for a longer term, you would allocate it normally with malloc or out of a pool as you describe.
I've heard of pooling but was under the impression that you were mallocing several memory allocations at once, but that the pieces of allocated memory were assigned to particular uses.
The primary benefit of this was to perform one malloc instead of N mallocs for N different memory assignments.
I didn't know that anyone used this to automatically reuse the memory assignments whenever and wherever appropriate.
About 15 years ago I started using a technique to improve performance when doing lots and lots of very short term mallocs.
Essentially, I'd create a large ring buffer of malloced temporary buffers of some standard length. Any time a temporary buffer was needed, I'd grab the next one in the ring.
Before the buffer was provided to the function asking for it, the length would be checked. If the requested length was longer than the current length, the buffer would be freed and one of at least the proper length would be allocated. (I normally allocated by buffers in byte multiples of some fixed constant, usually 32.)
The idea was that by the time it was reused, what was already in the buffer was no longer needed. To achieve that, I'd estimate how many buffers might be needed in the worst case and then multiply that number by 10 for safety's sake.
My primary use of this was when doing enormous numbers of allocations of memory for formatting purposes. The function doing the formatting would request a buffer large enough to hold whatever it would need, write the formatted data into the buffer, and then return a pointer to the buffer. The calling function would simply use the buffer and never have to worry about freeing it.
The performance results were superb except in the very simplest cases where you allocated the buffers without ever using them.
I've never known anyone else who used this kind of approach although I've showed it to a large number of people.
I usually ignore the politics, but that caused trouble at one company. My best luck has been with small companies where politics in less of an issue.
The largest company I ever worked for was right out of college. I didn't understand the politics and just concentrated on doing my job. Oddly enough, politics was never much of a problem there.
The one thing that most helped me there was when I was walking down the hall one day, happy after fixing a problem that had been bugging me for a couple of days. I ran into the two hatchetmen for the company, one of whom was my boss.
My boss asked me what I was up to and I told him how I had fixed the problem that had kept me busy the previous two or three days. His next question caught me by surprise when he asked "Who was at fault?" I asked him what he meant and he restated the question as "Who created the problem in the first place?" So I answered that it was me and a bit of what caused the problem. (After 25 years, I really don't remember what it was about.)
A couple of years later, my boss reminded me of that and told me that accepting responsibility for the problem instead of trying to shift the blame raised their estimates of me more than anything else I could have done. According to him, 99% of the people in the company would have tried to shift the blame elsewhere and the two of them found it refreshing to get an honest answer.
What I find disappointing is to run into someone with a technical or scientific degree of any kind who has no interest in or knowledge of any are that is not directly related to their own.
Most people with science degrees that I know do have broader areas of interest than just their area of expertise.
I've run into much wider variation of people with engineering degrees. Some have extremely broad knowledge many fields, and most have a very respectable range of knowledge. But there are a number who know nothing of areas beyond their limited range of interest.
Learn about the evolution of surgery including the development of "minimally invasive techniques" and the impact of performing those operations using robotics. Watch how "Zeus" a state-of-the-art robot, performs an operation under the guidance and direction of a UW surgeon. Then try your hand at being an anesthesiologist as you help "Chris," a robotic patient, undergo preparation for surgery.
I've only seen Part 1, so I'm looking forward to Part 2. I'll probably just wait for it to be broadcast again rather than watch it from the web cast.
Evan had a lawyer for a while. I think that after he had run out of money to pay the lawyer, the lawyer bowed out. From then on, I think Evan was pretty much on his own.
One of Evan's problems was that he wanted a jury trial but didn't understand that you must have a dispute over some fact to get the jury trial. If it is only a question of law, the judge can decide it without a jury trial.
For what it's worth, I knew Evan back in the 70s when we were both students at Texas A&M University.
At one previous company, my agreement with the president of the company was that I got to keep a copy of everything I wrote and could use it however I wished.
Copyright covers distribution. Space shifting and format shifting is definitely allowable. You are not allowed to distribute copies of songs to others, though casual copying is usually overlooked.
Copyright covers copying as well as distribution.
Making a copy without the permission of the copyright owner is usually a violation of copyright law unless the copyright owner has granted you the right to make the copy.
There are, of course, exceptions. The best known is when you copy only a small portion for certain purposes. Others include things like certain organizations that make copies of works for use by the blind or deaf.
You are correct that "casual copying is usually overlooked", but then that is what I already said, but in different words. It is usually overlooked, but it is still a copyright infringement.
I don't think that the RIAA is particularly worried about someone making a copy of something they already paid for. That is probably largeley because they prefer to claim that the entire piracy problem is p2p software related.
From what I've seen, most people don't make copies of their CDs unless they also distribute them by one way or another. There are exceptions, of course.
So if the RIAA could close down the file sharing applications, that would take care of probably 90% of the "problem".
Furthermore, many MP3 files are legal. For example, up to a year or so ago, someone who subscribed to eMusic could download up to about 2,000 tracks a month as part of their subscription, and a few did.
In any event, the music industry is attacking their concerns about things like MP3 players by trying to get everyone to use DRM.
It sounds like with Windoze, any of their developers could just check in their code with little or no oversight.
On Linux, all code gets inspected by others before it is accepted.
One thing the article didn't mention (at least, I didn't see it) is that the Windoze developers reportedly insert a large number of code segments to accomodate non-standard actions of particular programs or classes of programs written for prior versions of Windoze.
Actually, in most cases, ripping a song from a CD you purchased is also a copyright violation.
Many people try to claim that is legal because U.S. copyright law allows you to make a backup copy. But that argument is flawed because the law specifically refers to software. It does not extend to music CDs.
So, while you are unlikely to be caught making such copies, it is not a legal practice at all.
One obvious problem with such a scheme is that most users won't update the software every time a release is made available.
Suppose you fix a bug and release a new version. It will be some time before many people have switched to the new version and so you will, in the meantime, continue to get the same bug reports for a bug you've already exterminated.
The clear result is that of the latest 100 bug reports received, most will likely be completely useless.
Slashdot Mirror
They had both post-increment and pre-decrement as well as deferred post-increment and deferred pre-decrement.
Even better was the Data General Nova. It had autoincrement and autodecrement locations in memory. Access one of those locations and the contents would be automatically incremented (or decremented) as part of the operation.
In some cases, the idea is clearly to make the software comfortable to people to make it easier for them to migrate to it.
Kind of like Trolltech's license approach for Qt.
You got it.
It would be unsafe if there was any possibility of the buffers needing to stay around very long. Like I said, I generally allocate 10x the maximum number I really think I'll need just to be safe. In general, my goal is performance, limiting heap fragmentation, or both.
I've never tried to use this where it wasn't appropriate -- i.e., where the buffer was needed for more than just a very short-term thing.
Of course, you couldn't use this in a multi-threaded program unless only one thread needed short term buffers. For a multi-threaded program, you would really need to have a separate allocation of buffers per thread or use a method of locking the buffers and not reallocating those buffers that are still locked.
What you are describing is for an entirely different type of problem.
What you are describing will require a search of the bitmap to locate an available buffer. It will also require that the program mark the buffers as available once they are no longer needed.
That is not at all what I was describing.
What I was describing was reusing buffers without needing to check whether or not they were being used by anything else because of the nature of the use of those buffers, i.e. by the very limited time the buffers would be used and by using the least recently used buffer, there is no need to check to see if they are being used because they would always be available.
And, of course, for that type of thing, LRU is pretty much required. I guess you could use the next to the least recently used buffer, but there wouldn't be any point of doing that.
In other words, the buffers are immediately available with no need to search for an available buffer. Just choose the next buffer (which is the least recently used).
My scheme also allows you to increase the buffer size if the available buffer size is too small.
In what I was describing, you would typically allocate N buffers with N mallocs. Then, when a buffer was too small, you just free that buffer and malloc it with a larger request.
By the way, I never claimed that a linked list structure was central. You could just as easily maintain an array of 100 pointers and an index into the array to find the location of the LRU buffer. It is O(1) either way.
The first time I ever did this, I allocated the N buffers with one malloc and had a flag bitmap that indicated whether or not each buffer was a buffer or a pointer to a larger buffer. Thus, in most cases, it performed one malloc and one free, did not require a search to find an available buffer, and temporary assignments were usually constant time.
What I described was to allocate a list of buffers and reuse them for very short termed uses without needing to check to see if what was using them before was finished with them.
In other words, you could conceivably have 1,000 or more functions sharing some fixed number of buffers (say 100 buffers) between them. When a function needs a buffer, it would just grab the least recently used buffer and reuse it.
The idea depends on the buffers being used for a short enough time that when you need a new buffer, whatever was using the least recently used buffer no longer has any need of it.
It's really a much different idea.
If you needed something for a longer term, you would allocate it normally with malloc or out of a pool as you describe.
I've heard of pooling but was under the impression that you were mallocing several memory allocations at once, but that the pieces of allocated memory were assigned to particular uses.
The primary benefit of this was to perform one malloc instead of N mallocs for N different memory assignments.
I didn't know that anyone used this to automatically reuse the memory assignments whenever and wherever appropriate.
Thanks for the information.
About 15 years ago I started using a technique to improve performance when doing lots and lots of very short term mallocs.
Essentially, I'd create a large ring buffer of malloced temporary buffers of some standard length. Any time a temporary buffer was needed, I'd grab the next one in the ring.
Before the buffer was provided to the function asking for it, the length would be checked. If the requested length was longer than the current length, the buffer would be freed and one of at least the proper length would be allocated. (I normally allocated by buffers in byte multiples of some fixed constant, usually 32.)
The idea was that by the time it was reused, what was already in the buffer was no longer needed. To achieve that, I'd estimate how many buffers might be needed in the worst case and then multiply that number by 10 for safety's sake.
My primary use of this was when doing enormous numbers of allocations of memory for formatting purposes. The function doing the formatting would request a buffer large enough to hold whatever it would need, write the formatted data into the buffer, and then return a pointer to the buffer. The calling function would simply use the buffer and never have to worry about freeing it.
The performance results were superb except in the very simplest cases where you allocated the buffers without ever using them.
I've never known anyone else who used this kind of approach although I've showed it to a large number of people.
I usually ignore the politics, but that caused trouble at one company. My best luck has been with small companies where politics in less of an issue.
The largest company I ever worked for was right out of college. I didn't understand the politics and just concentrated on doing my job. Oddly enough, politics was never much of a problem there.
The one thing that most helped me there was when I was walking down the hall one day, happy after fixing a problem that had been bugging me for a couple of days. I ran into the two hatchetmen for the company, one of whom was my boss.
My boss asked me what I was up to and I told him how I had fixed the problem that had kept me busy the previous two or three days. His next question caught me by surprise when he asked "Who was at fault?"
I asked him what he meant and he restated the question as "Who created the problem in the first place?" So I answered that it was me and a bit of what caused the problem. (After 25 years, I really don't remember what it was about.)
A couple of years later, my boss reminded me of that and told me that accepting responsibility for the problem instead of trying to shift the blame raised their estimates of me more than anything else I could have done. According to him, 99% of the people in the company would have tried to shift the blame elsewhere and the two of them found it refreshing to get an honest answer.
What I find disappointing is to run into someone with a technical or scientific degree of any kind who has no interest in or knowledge of any are that is not directly related to their own.
Most people with science degrees that I know do have broader areas of interest than just their area of expertise.
I've run into much wider variation of people with engineering degrees. Some have extremely broad knowledge many fields, and most have a very respectable range of knowledge. But there are a number who know nothing of areas beyond their limited range of interest.
I still prefer BSD servers.
Linux is good for a nice desktop, but it will be a long time before I replace a BSD server with Linux.
It was much better than that.
Here are some links to the show. You can watch it on-line if you don't have Dish Network or your local cable doesn't carry the channel.
A Kinder Cut: Nintendo Surgery Part 1
A Kinder Cut: Nintendo Surgery Part 2
I've only seen Part 1, so I'm looking forward to Part 2. I'll probably just wait for it to be broadcast again rather than watch it from the web cast.
There was a nice demonstration of such a system a couple of weeks ago on UWTV (University of Washington TV).
The robot was used for instruction for surgeons and anaesthesiologists.
Evan had a lawyer for a while. I think that after he had run out of money to pay the lawyer, the lawyer bowed out. From then on, I think Evan was pretty much on his own.
One of Evan's problems was that he wanted a jury trial but didn't understand that you must have a dispute over some fact to get the jury trial. If it is only a question of law, the judge can decide it without a jury trial.
For what it's worth, I knew Evan back in the 70s when we were both students at Texas A&M University.
At one previous company, my agreement with the president of the company was that I got to keep a copy of everything I wrote and could use it however I wished.
I wish I had thought of saying it like that.
Copyright covers copying as well as distribution.
Making a copy without the permission of the copyright owner is usually a violation of copyright law unless the copyright owner has granted you the right to make the copy.
There are, of course, exceptions. The best known is when you copy only a small portion for certain purposes. Others include things like certain organizations that make copies of works for use by the blind or deaf.
You are correct that "casual copying is usually overlooked", but then that is what I already said, but in different words. It is usually overlooked, but it is still a copyright infringement.
That argument is nonsense.
I don't think that the RIAA is particularly worried about someone making a copy of something they already paid for. That is probably largeley because they prefer to claim that the entire piracy problem is p2p software related.
From what I've seen, most people don't make copies of their CDs unless they also distribute them by one way or another. There are exceptions, of course.
So if the RIAA could close down the file sharing applications, that would take care of probably 90% of the "problem".
Furthermore, many MP3 files are legal. For example, up to a year or so ago, someone who subscribed to eMusic could download up to about 2,000 tracks a month as part of their subscription, and a few did.
In any event, the music industry is attacking their concerns about things like MP3 players by trying to get everyone to use DRM.
It sounds like with Windoze, any of their developers could just check in their code with little or no oversight.
On Linux, all code gets inspected by others before it is accepted.
One thing the article didn't mention (at least, I didn't see it) is that the Windoze developers reportedly insert a large number of code segments to accomodate non-standard actions of particular programs or classes of programs written for prior versions of Windoze.
Actually, in most cases, ripping a song from a CD you purchased is also a copyright violation.
Many people try to claim that is legal because U.S. copyright law allows you to make a backup copy. But that argument is flawed because the law specifically refers to software. It does not extend to music CDs.
So, while you are unlikely to be caught making such copies, it is not a legal practice at all.
I've never lost any money in Las Vegas and have never known anyone who did.
And I've been to Las Vegas, New Mexico a number of times.
If all you get is the 100 latest entries and you ignore the 70 or 80 entries available that pertain to previous versions, then you only have 20 left.
It would be much better to filter out the prior versions first.
One obvious problem with such a scheme is that most users won't update the software every time a release is made available.
Suppose you fix a bug and release a new version. It will be some time before many people have switched to the new version and so you will, in the meantime, continue to get the same bug reports for a bug you've already exterminated.
The clear result is that of the latest 100 bug reports received, most will likely be completely useless.
I've stood within a couple feet of more than one research reactor that used lasers to initiate fusion.
And they used magnetic fields to attempt to contain the resulting plasma.
That was in 1972.
It could be the best browser in the world, but I wouldn't use it unless it were available on more than just one platform.
It would be another matter if there were no multi-platform browsers.