Memory usage does vary from machine to machine. Mostly I see a lot of memory leaks every I run Linux in any kind of GUI mode. It seems like the Swap doesn't work well either. Though, if I have more than a gig of memory in the box everything seems great.
Also, I see speed vary from machine to machine too. I've found that recompiling the kernel has a tremendous impact on speed every time. It usually increases responsiveness by about double.
I think Windows gets around this particual problem by having a kernel that can adapt very well to the various different processors it is installed on. Linux distros could improve on this during installation, and I think that a lot of people would say that the performance is much better. Basically compile several kernels, and poll the hardware for which one is best to install.
I've found that the whole system is much faster if some of the plugin modules are just directly compiled in. It doesn't typically bloat my kernel very much, because there is a lot of unused features in there that I just unselect.
Another helpful thing that I've found when that slow down problem occurs -- turn off swap... swap is terrible under Linux. Swap is at least mediocre on windows. Turning off swap in Linux makes it so that if I leak too much memory it doesn't get swapped to disk, and when it is needed again at least it is pulling from a faster memory store.
And instead of a command line interface, I would like to see a unified way of handling dependencies in libaries, and also a unified way of searching through api of the libraries available on the system. (Directly from the libraries themselves, ala the.Net Framework object browser)
A well integrated GUI development environment would be nice too. One that you can drop a button, or a text box on a form, and the double click on the button or textbox to add an event to it. Like Kylix except supported through version upgrades of Linux. Kdevelop isn't there yet.
It doesn't carry more weight. It just shows that there is a difference, and that life behind the counter of a video game store is not the same across the board. In particular it is not even close to the depiction of the blog.
One experience does not equal another, so pay no heed to how this article submission title as an overgeneralization to a retail industry.
I can't believe this even made it into slashdot as it has almost no redeeming qualities of legitimacy.
It got pointed to as an article on slashdot... so I was pointing out that there are differences and that there way might not necessarily be the same. That was exactly my point. You were just ignorant, and needed to restate the obvious.
I own a video game store, and the first couple paragraphs are hugely wrong as a whole... except for the people with birds on their shoulder part, as I've seen that too.
For one thing you don't know what has not occurred yet. That is called a guess. For another women/girls like videogames too. Maybe not I New Jersey, but In Washington State they do.
The people are also no stranger than you would get in say a Jack in the Box, or a Mervyns. Which is not to say that those people aren't strange too.
Anyway, just ignore this stupid article. I wish that I had.
It's important (to me anyway) to point out that it could not be a bunch of TNT due to several simple principles.
It's underground -- free oxygen is need to blow up tnt and would get used up quickly.
It's a big problem keeping the TNT from blowing up other TNT before it gets its own chance to blow up. In other words its chain reaction does not happen the way a fission reaction occurs.
That's not to say that there aren't ways around those problems, but personally I think it would be easier to just make a nuclear bomb in the first place. Kind of like it would be a bit on par to land on the moon as it is to fake some of the things that are properties of the moon and space.
Keep in mind that most people in Korea are black belts (at least) in Tae Kwon Do. The must like games too. I for one am glad to see them expand into more forms of entertainment and other areas of social activity.
Also, I for one welcome my Martial Arts Master Video Game Playing Overlords.
I've read many (around 15) data structures and algorythms books.
Here is the best one that you will still be able to get in print:
Tomes of delphi: algorithms and data structures
Julian M Bucknall
It covers advanced structures and walks you through improvements on algorythms.
Basically it teaches you why and how some algorythms are most suited to various situations.
Also, since it is in Pascal it is usually easier to port the code to more modern languages than C.
The only drawback in this book is its binary tree algorythm, which I don't like and don't understand (his version anyway). Though I have several other books that cover that well, and since you are looking for more advanced stuff then you won't need that particular tree algorythm either.
I think he is onto something there. A few of his predictions align with what I know about my field, so I think they deserve some moderate credibility. One helpful idea that I use is the comparison of now to 15 years ago, and see what is different. In 1990 no one (read almost everyone) had the PDA or the internet, but we had the paper notebook, the phone, and the encyclopedia britanica. Fairly good stand-ins. Just look at everything in incremental improvements and try and predict a few of them out. I think that's what he is trying to do.
They scare me for those same reasons plus one more really big one. They can kill off anyone on both sides. They are indiscriminate against friend and foe, and can kill off people who are not involved in the war at all. (Same problems as fallout from a mushroom cloud that circles the globe a few times, except much more extreme)
There is every reason to think that this machine could do a lot more than power a bronco, or work inside of a toothbrush, or some other retarded and small task.
In 1997 I learned how to program on a computer that ran on less than 10 mghz and had far less ram and memory than this device. It also didn't have network connectivity or anything like that.
So, what's my point?
Basically, I could use this device to do wordprocessing, browse the internet, perform distributed supercomputing tasks (read beowolf cluster of these), play civilization, or where in the world is carmen san diego. I could make CAD drawings of shopping malls, or whatever. The point is that this affords more computing power than most people realize, because they've never been crunched for processing power. Remember all those PDA's and cellphones probably have lower or nearly equivilant specs to this little device and some of them cost quite a bit more.
Another typical use for a threaded application would be to make one process that takes a long time to work, and help it finish up more quickly.
Ie.) sort through a terrain, for better level of detail.
Ie.) allow a bunch more AI to operate at the same time.
I agree with your design statement towards the end your post, but the multiple inputs anology that you make isn't very good since, it doesn't really apply very well nowadays, and didn't really apply very well 10 years ago either. Also, moving the camera is a fairly linear task and as far as I can see doesn't lend itself well to being parallelized.
Basically a good point, with a poor analogy. I'll try to improve on it a little here.
The multiple inputs that you mention while executing other tasks has been taken care of in hardware for quite a while already.
Another thing to point out, is that if you know you are going to have more than one core, then you can fairly easily plan for a bunch more cores. Threads and processes make this easy, since their paradigm has been around for a long time and programmers are already used to the idea.
The problems really start to creep in while you are testing to make sure that all cases work correctly. Though, I would argue that this is harder to do with any multithreaded application.
So, then, if you ask me, then the big waiting game we are playing is that there aren't a whole bunch of programmers with the kind of experience necessary to root out these very difficult bugs that occur. These are the kind of bugs that everyone has seen from time to time... Oh, that was wierd!... Try it again... hmmm, seems to work fine now. They just happen a lot more often when the threads are actually executing on different processors, instead of just in different time slices on the same processor.
So, I'm sure that in about 5 years there will be some good tools to help the other programmers figure out these issues more easily. I look forward to that and welcome my multi-core overlords.
Responding to the speedup, I just wanted to point out that their is often a diminishing return on the number of processors being thrown at a problem.
here is a hypothetical situation of a process that takes 10 seconds to run
We are assuming a perfrect speedup, at every additonal processor (which is not true in reality)
1 cpu = 10 seconds of runtime
2 cpu = 5 seconds of runtime
4 cpu = 2.5 seconds of runtime
everything below here is going to seem instantaneous to a web user or a database user.
8 cpu = 1.75 seconds of runtime
16 cpu =.83 seconds of runtime
32 cpu =.41 seconds of runtime
everything below here is going to seem instantaneeous to a user of a software application on a local machine
I'm just going to point out how much of an exageration that is, so please don't think that I believe you mean that 24th century comment literally. I mainly just thought it would be fun to list some of these ideas.
3 centuries ago, people were still battling with swords, there were no airplanes, computers, or cars.
There was no electricity to speak of.
Chemistry and physics had not really been worked out. Biology too.
The world had not been mapped out by everyone.
There were no sattelites or communications network.
3 centuries from now will be just as different.
Computers or chips that communicate with computers will be implanted or worn on the body. This will allow immediate access to information (reminds me of who am I talking with, buy stuff instantly by walking out of the store with it, call a friend instantly, start the food cooking or order it on your way home, keyless access to everything that needed a key before)
Homes will probably be on average smaller.
Bussinesses will be more closely packed together.
Air purifying machines will be necessary.
Water will become more of a commodity.
Space travel will be quite a bit more routine.
We'll likely have visited more than one planet in our solar system by then.
Better medicine, longer lives.
Fully immersive entertainment will probably be the biggest change.
How do I know all this? I'm from the future!!!
Just kidding.
It's mostly fairly obvious, and most of it will likely have in the next century and a half.
The biggest (not necessarily the most important changes) will be unknown until they occur.
Of course this is all predicated on not having a lot of major wars getting in the way of technological advancement for the well being of everyone. We'll see.
Dude, it was just released. Give it a chance to be used, before you complain that no-one uses it. Someone put a tonne of effort into it, and you should have some respect for that at the very least.
I find it odd that when making recollection about older games that they never think about the fact that most of the older games, both looked ugly and played badly. At least today, most games have at least the looks category covered.
The games that people remember tend to be the good/original titles. ie.) Super Mario Bros. Zelda, Contra
I was given a free copy of the book, by the publisher, in exchange for posting about it or telling my friends about it. In short, the books is not written for the pragmatist. It is written to give a pretty good description of the internals of UML, which is honestly, not very useful.
A couple of chapters devoted to usage and practical applications would help. A comparison where uml is better than other alternatives would help.
The literature also gets buried in its own details, just as if it is reading like source code might. This is not a good writing style for english.
Yes that is correct, but at least there is a path to actually get a working driver. Before this, there was almost no hope at all to get a working driver installed in less than 4 hours.
For all the people out there that are about to go on about apt-get or some stupid distro, here this: give it up. while (my-dsitro <= your-distro) my-distro++;
To illustrate, the reasons that Linux is not the dominant Operating system.
Linux should have the following priorities in mind to gain wider acceptance:
We need to get a truly working pluggable driver model.
We need to have a registry to track applications, and their installation paths, and installation parameters. (This will help with the install, uninstall, and dependency headaches)
We need a unified configuration system and configuration user interface.
We need a great GUI development IDE
We need to not release products with 200 dependencies that change every 4 weeks
The only thing Linux has over other operating systems right now, is price.
The Flexibility open source should provide is hampered too much by the above listed problems.
Funny that you mention design. I've never seen a project except for the ones that I develop from a spec that I wrote myself, even come close to meeting spec.
Databases are fairly proprietary, and a class on databases should be specific to a platform and if oracle is used then oracle is what matters. Besides oracle is number one in the database market right now, so that seems just fine to me either way. They are the standard.
Unless there is some more to the story (is there?) then the the professor did the right thing.
If the data is stored in Ram, and there are multiple threads working, you could saturate the connection. True, that you will likely just be saturating the network switch more often though.
Slashdot Mirror
Memory usage does vary from machine to machine. Mostly I see a lot of memory leaks every I run Linux in any kind of GUI mode. It seems like the Swap doesn't work well either. Though, if I have more than a gig of memory in the box everything seems great.
.Net Framework object browser)
Also, I see speed vary from machine to machine too. I've found that recompiling the kernel has a tremendous impact on speed every time. It usually increases responsiveness by about double.
I think Windows gets around this particual problem by having a kernel that can adapt very well to the various different processors it is installed on. Linux distros could improve on this during installation, and I think that a lot of people would say that the performance is much better. Basically compile several kernels, and poll the hardware for which one is best to install.
I've found that the whole system is much faster if some of the plugin modules are just directly compiled in. It doesn't typically bloat my kernel very much, because there is a lot of unused features in there that I just unselect.
Another helpful thing that I've found when that slow down problem occurs -- turn off swap... swap is terrible under Linux. Swap is at least mediocre on windows. Turning off swap in Linux makes it so that if I leak too much memory it doesn't get swapped to disk, and when it is needed again at least it is pulling from a faster memory store.
And instead of a command line interface, I would like to see a unified way of handling dependencies in libaries, and also a unified way of searching through api of the libraries available on the system. (Directly from the libraries themselves, ala the
A well integrated GUI development environment would be nice too. One that you can drop a button, or a text box on a form, and the double click on the button or textbox to add an event to it. Like Kylix except supported through version upgrades of Linux. Kdevelop isn't there yet.
Just my two cents.
True enough. I over-reacted. Please accept my apology.
It doesn't carry more weight. It just shows that there is a difference, and that life behind the counter of a video game store is not the same across the board. In particular it is not even close to the depiction of the blog.
One experience does not equal another, so pay no heed to how this article submission title as an overgeneralization to a retail industry.
I can't believe this even made it into slashdot as it has almost no redeeming qualities of legitimacy.
It got pointed to as an article on slashdot... so I was pointing out that there are differences and that there way might not necessarily be the same. That was exactly my point. You were just ignorant, and needed to restate the obvious.
I own a video game store, and the first couple paragraphs are hugely wrong as a whole... except for the people with birds on their shoulder part, as I've seen that too.
For one thing you don't know what has not occurred yet. That is called a guess. For another women/girls like videogames too. Maybe not I New Jersey, but In Washington State they do.
The people are also no stranger than you would get in say a Jack in the Box, or a Mervyns. Which is not to say that those people aren't strange too.
Anyway, just ignore this stupid article. I wish that I had.
It's important (to me anyway) to point out that it could not be a bunch of TNT due to several simple principles.
It's underground -- free oxygen is need to blow up tnt and would get used up quickly. It's a big problem keeping the TNT from blowing up other TNT before it gets its own chance to blow up. In other words its chain reaction does not happen the way a fission reaction occurs.
That's not to say that there aren't ways around those problems, but personally I think it would be easier to just make a nuclear bomb in the first place. Kind of like it would be a bit on par to land on the moon as it is to fake some of the things that are properties of the moon and space.
Keep in mind that most people in Korea are black belts (at least) in Tae Kwon Do. The must like games too. I for one am glad to see them expand into more forms of entertainment and other areas of social activity.
Also, I for one welcome my Martial Arts Master Video Game Playing Overlords.
I've read many (around 15) data structures and algorythms books. Here is the best one that you will still be able to get in print: Tomes of delphi: algorithms and data structures Julian M Bucknall It covers advanced structures and walks you through improvements on algorythms. Basically it teaches you why and how some algorythms are most suited to various situations. Also, since it is in Pascal it is usually easier to port the code to more modern languages than C. The only drawback in this book is its binary tree algorythm, which I don't like and don't understand (his version anyway). Though I have several other books that cover that well, and since you are looking for more advanced stuff then you won't need that particular tree algorythm either.
Basically, this company got robbed of thier intellectual property.
They really did have a great thing that people wanted to use.
It's just that licenses should have been bought, by the vendors that were bundling it.
I think he is onto something there. A few of his predictions align with what I know about my field, so I think they deserve some moderate credibility. One helpful idea that I use is the comparison of now to 15 years ago, and see what is different. In 1990 no one (read almost everyone) had the PDA or the internet, but we had the paper notebook, the phone, and the encyclopedia britanica. Fairly good stand-ins. Just look at everything in incremental improvements and try and predict a few of them out. I think that's what he is trying to do.
They scare me for those same reasons plus one more really big one.
They can kill off anyone on both sides.
They are indiscriminate against friend and foe, and can kill off people who are not involved in the war at all.
(Same problems as fallout from a mushroom cloud that circles the globe a few times, except much more extreme)
This is a lot of power.
There is every reason to think that this machine could do a lot more than power a bronco, or work inside of a toothbrush, or some other retarded and small task.
In 1997 I learned how to program on a computer that ran on less than 10 mghz and had far less ram and memory than this device. It also didn't have network connectivity or anything like that.
So, what's my point?
Basically, I could use this device to do wordprocessing, browse the internet, perform distributed supercomputing tasks (read beowolf cluster of these), play civilization, or where in the world is carmen san diego. I could make CAD drawings of shopping malls, or whatever. The point is that this affords more computing power than most people realize, because they've never been crunched for processing power. Remember all those PDA's and cellphones probably have lower or nearly equivilant specs to this little device and some of them cost quite a bit more.
Thanks... (Get's down off of soap box)
Another typical use for a threaded application would be to make one process that takes a long time to work, and help it finish up more quickly.
... Try it again ... hmmm, seems to work fine now. They just happen a lot more often when the threads are actually executing on different processors, instead of just in different time slices on the same processor.
.83 seconds of runtime
.41 seconds of runtime
Ie.) sort through a terrain, for better level of detail.
Ie.) allow a bunch more AI to operate at the same time.
I agree with your design statement towards the end your post, but the multiple inputs anology that you make isn't very good since, it doesn't really apply very well nowadays, and didn't really apply very well 10 years ago either. Also, moving the camera is a fairly linear task and as far as I can see doesn't lend itself well to being parallelized.
Basically a good point, with a poor analogy. I'll try to improve on it a little here.
The multiple inputs that you mention while executing other tasks has been taken care of in hardware for quite a while already.
Another thing to point out, is that if you know you are going to have more than one core, then you can fairly easily plan for a bunch more cores. Threads and processes make this easy, since their paradigm has been around for a long time and programmers are already used to the idea.
The problems really start to creep in while you are testing to make sure that all cases work correctly. Though, I would argue that this is harder to do with any multithreaded application.
So, then, if you ask me, then the big waiting game we are playing is that there aren't a whole bunch of programmers with the kind of experience necessary to root out these very difficult bugs that occur. These are the kind of bugs that everyone has seen from time to time... Oh, that was wierd!
So, I'm sure that in about 5 years there will be some good tools to help the other programmers figure out these issues more easily. I look forward to that and welcome my multi-core overlords.
Responding to the speedup, I just wanted to point out that their is often a diminishing return on the number of processors being thrown at a problem.
here is a hypothetical situation of a process that takes 10 seconds to run
We are assuming a perfrect speedup, at every additonal processor (which is not true in reality)
1 cpu = 10 seconds of runtime
2 cpu = 5 seconds of runtime
4 cpu = 2.5 seconds of runtime
everything below here is going to seem instantaneous to a web user or a database user.
8 cpu = 1.75 seconds of runtime
16 cpu =
32 cpu =
everything below here is going to seem instantaneeous to a user of a software application on a local machine
After this, I'm going back to 1985, to welcome my time traveling overlords!!! :)
I'm just going to point out how much of an exageration that is, so please don't think that I believe you mean that 24th century comment literally. I mainly just thought it would be fun to list some of these ideas. 3 centuries ago, people were still battling with swords, there were no airplanes, computers, or cars. There was no electricity to speak of. Chemistry and physics had not really been worked out. Biology too. The world had not been mapped out by everyone. There were no sattelites or communications network. 3 centuries from now will be just as different. Computers or chips that communicate with computers will be implanted or worn on the body. This will allow immediate access to information (reminds me of who am I talking with, buy stuff instantly by walking out of the store with it, call a friend instantly, start the food cooking or order it on your way home, keyless access to everything that needed a key before) Homes will probably be on average smaller. Bussinesses will be more closely packed together. Air purifying machines will be necessary. Water will become more of a commodity. Space travel will be quite a bit more routine. We'll likely have visited more than one planet in our solar system by then. Better medicine, longer lives. Fully immersive entertainment will probably be the biggest change. How do I know all this? I'm from the future!!! Just kidding. It's mostly fairly obvious, and most of it will likely have in the next century and a half. The biggest (not necessarily the most important changes) will be unknown until they occur. Of course this is all predicated on not having a lot of major wars getting in the way of technological advancement for the well being of everyone. We'll see.
Dude, it was just released. Give it a chance to be used, before you complain that no-one uses it.
Someone put a tonne of effort into it, and you should have some respect for that at the very least.
I find it odd that when making recollection about older games that they never think about the fact that most of the older games, both looked ugly and played badly. At least today, most games have at least the looks category covered.
The games that people remember tend to be the good/original titles. ie.) Super Mario Bros. Zelda, Contra
Does anyone else have thoughts about this notion?
I was given a free copy of the book, by the publisher, in exchange for posting about it or telling my friends about it.
In short, the books is not written for the pragmatist. It is written to give a pretty good description of the internals of UML, which is honestly, not very useful.
A couple of chapters devoted to usage and practical applications would help.
A comparison where uml is better than other alternatives would help.
The literature also gets buried in its own details, just as if it is reading like source code might. This is not a good writing style for english.
For all the people out there that are about to go on about apt-get or some stupid distro, here this: give it up.
while (my-dsitro <= your-distro) my-distro++;
To illustrate, the reasons that Linux is not the dominant Operating system.
Linux should have the following priorities in mind to gain wider acceptance:
The only thing Linux has over other operating systems right now, is price.
The Flexibility open source should provide is hampered too much by the above listed problems.
Funny that you mention design. I've never seen a project except for the ones that I develop from a spec that I wrote myself, even come close to meeting spec.
It usually goes something like this throughout all product categories.
Like most people, If I do a search that doesn't give me what I want in the first few pages. I just do another search with different keywords.
I doubt that was a factor that is taken into account.
Databases are fairly proprietary, and a class on databases should be specific to a platform and if oracle is used then oracle is what matters. Besides oracle is number one in the database market right now, so that seems just fine to me either way. They are the standard.
Unless there is some more to the story (is there?) then the the professor did the right thing.
If the data is stored in Ram, and there are multiple threads working, you could saturate the connection. True, that you will likely just be saturating the network switch more often though.
I for one welcome myself and my new overlord. :)