Caching, at all levels of computing, gives enormous performance gains. In the DNS world, without caching, everyone would hit top level domains which would introduce a serious bottleneck to what should be a distributed system.
If you don't understand why that's an excellent reason or why it's useful, then you have an even poorer understanding of how DNS works and why it's around than I do, and I admit my understanding is rudimentary.
Correct. But it's a critical assumption, and without it, the entire line of reasoning falls apart. Not stating that up front - as neither you or the author of the article did - either means you left it out on purpose, which is deceitful, or you left it out unintentionally, which means you have a fundamental misunderstanding of the issue at hand.
But where the numbers do make a difference - because there are more users, there are more hackers out there trying to find and exploit these holes so you will see an increase. I am sure that if the market share were reversed (I.E. having 8% or whatever the number is, and the rest going to FireFox) so would the numbers for flaws. Security through obscurity - the door swings both ways.
I understand your argument clearly; you don't need to restate it again. However, your argument still has the assumption that Firefox and IE have about the same number of flaws to be found. That is the only reasonable way for the the number of discovered flaws to exchange between the two if the market share was also exchanged. That assumption is not necessarily true.
More users = more amount of people finding flaws that already existed.
That's always been clear. However, when you try to apply that to Firefox, you're reversing the causality, which isn't necessarily true. That is, you're assuming that the less number of users is the cause for the less number of discovered flaws. It very well may be that there are less number of discovered (severe) flaws because Firefox is inherently more secure. If it is, then the discovery of severe flaws should be relatively independent of the number of users.
So the amount of time they are around is really not that much of an issue for our conversation.
Time itself wasn't really my focus, but the implication that something that's been around for a long time has been banged on pretty hard. The reason I brought up the fact that Unix and related technologies have been around longer than Windows is to address the argument the author made, and I felt you implied: Windows is used more than Linux, so it's okay that Windows has more discovered flaws. That argument implies that Linux has flaws sitting around waiting to be discovered (which I think is true), and that they probably have about the same number of flaws (which I don't think is true).
I talked above about why that argument is invalid. I brought up the issue of number of users and how long its been around to challenge the assumptions of the argument.
Fact 1: Firefox hasn't shown that many security flaws in the past Fact 2: it had fewer (95%?) using it then IE Fact 3: those people using it were (mostly) more advanced then the typical IE/AOL user
Notice I left out two words: "because" and "and." Fact 1 is not necessarily caused by facts 2 and 3. That's a logical fallacy. There are other unmentioned facts which might actually be the cause of fact 1. Both you and the article's author made this logical fallacy.
the more people that use it [Linux], the more problems will come to light.
A point that you, and the article's author, overlook is that Windows is actually the new kid on the block, not Linux. While Linux itself has not been around as long as Windows, the technology Linux is based on (i.e., Unix and all related tools and platforms) have been around much longer than Windows. (In this context, when I say "Windows" I mean NT, 2000 and XP.) Furthermore, Linux and related Unix based OSes have been on the front line as servers far longer and in greater numbers than Windows has. So using the above fallacy for Linux breaks in two ways: it's not actually the new, underused one.
For the record, I am both a Linux and Windows user. I do most of my work on a Linux box at the office, but my home machine is Windows. I use Firefox on both, mainly because it has the best functionality.
True. I always thought there was nobility in failing a few classes in college. If you didn't fail a few, you weren't really pushing yourself hard enough. My transcript represented this worldview pretty well.
I don't understand how not pushing yourself follows from not failing a few classes.
I graduated with a BS in CS from Virginia Tech in 2003. There was no mention of using anything Apple in the department while I was there. In fact, they seemed to be strengthening their relationship with Microsoft through the MS Academic Alliance. Some classes required working on Linux, but most were on Windows.
Note: This has nothing to do with the big honking cluster of Apple machines. I'm talking about what faculty have on their desks, what it's in the labs, and what students are expected to work on.
Not really. I wrote something similar last week when I was trying to figure out how much extra memory valgrind needs to run a program. Linux eventually kills your program if you're using too much memory. In my case, "too much" was when I started asking for so much memory that I would be above the 4 gig limit.
If you really want to bring a system to a crawl, the best thing to do is figure out how much RAM it has. Request more memory than that so that the system is forced to swap pages to disk. Then do some memory intensive operations over all of the memory indefinitely. For example, a matrix multiplication inside a while(true) where the combined size of the matrices is larger than main memory should do it. This won't cause the system to crash, but it will be extremely slow since it's constantly doing disk I/O.
Re:If GCC can compile C++, then...
on
GCC 4.0 Preview
·
· Score: 4, Informative
g++ is basically an easy way of calling gcc for C++. From the gcc and g++ manpage:
However, C++ programs often require class libraries as well as a compiler that understands the C++ language---and under some circumstances, you might want to compile programs from standard input, or otherwise without a suffix that flags them as C++ programs. g++ is a program that calls GCC with the default language set to C++, and automatically specifies linking against the C++ library. On many systems, g++ is also installed with the name c++.
We've been able to obtain truly random numbers for a long, long time. All you need to do is get information from some physical device - the Linux kernel has a random function that gets some random information from the keyboard. Sound cards work too.
But in most applications, a simple pseudo-random number generator is going to be indistinguishable from truly random numbers.
Right now, the Linux 2.4 kernel sees Pentium 4's with HyperThreading as two processors. The 2.6 kernel sort of sees them as two processors, but is aware that it's not the same as having two actual processors and does scheduling and load balancing a little differently (I think). Windows reports two processors, but I don't know if they've done anything special.
Dual core is different, but I think that this is basically what we'll see. The OS will report both cores as two distinct processors for most purposes, but when it comes to scheduling and load balancing, they'll probably take into account that it's not actually two processors. Since it seems CMP (Chim Multiprocessor; Intel and AMD are calling it dual core) and SMT (Symmetric Multithreading; Intel's implemenation is HyperThreading) are the direction processors are heading, operating systems will have to be aware of their architecture in order to take full advantage of them.
And this is an important point: they aren't two invdividual processors, and treating them as such can sometimes have drawbacks. (I know this is true with HT chips, and I think this will also be true for dual core chips.)
What CMP and SMT being on desktop machines might indicate is that multiprocessor machines (in general) might start to become the norm. And if that's true, then the practice of licensing software per CPU might no longer be valid.
Security experts in academia? I realize that some (a lot?) of them are more theoretical, but seems to be a good place to start. I know some research groups have been the ones to first report various security holes in software.
The difficulty with people in a VP position is there's no way of knowing if they have a technical background; I was part of a small startup company where our VP of engineering was also a primary developer, but it's not necessarily the case. My gut reaction is he's just presenting information that he thinks is in the best interest of the company - which, afterall, is his job.
Their expert is the Vice President of Threat Research at Webroot. That much is from the article. The article doesn't take the next logical step, however, and point out that Webroot is in the business of developing and selling software to prevent, detect and eleminate spyware. So it's certainly in this guy's interest for people to think that spyware is still a problem.
Their other expert is also from a company that makes similar software. So people who make anti-spyware software agree: you need anti-spyware software.
I'll be more concerned when independent parties think spyware in Firefox is an issue.
Considering that it's free, I don't think people have grounds to complain. In this case, and in others, they need to do extensive testing before it's non-Beta. How else can you do that without releasing it?
The chip makers have always been trying to squeeze more performance out of a chip. For the past ten years or so, upping the clock speed has been the easiest way to do that. Upping the clock speed is getting harder and the gains are smaller. So what they're trying to do is explore other ways of increasing the performance from a single chip. Right now, dual core looks like a better way of using the transistors on the chip.
No. That's a cluster, which is a different beast. Communication between nodes in a cluster requires message passing, usually over ethernet. Dual core is closer to SMPs, which means shared memory. Communicating via shared memory is faster.
Think about it this way. Let's say you and a friend are working on a math problem. An SMP is you both have your own sheet of paper, but you can read and write on his sheet of paper, and he can do the same to yours. A dual core is you both share the same piece of paper. A cluster if you both have seperate sheets of paper, and you can only communicate over the phone.
No, that will actually be just as bad as having two threads doing lots of floating point calculations. Codes with lots of branches make heavy use of the integer units. The most gain to be had is probably by having one thread that is compute bound and the other is I/O bound.
I really don't know. I can make lots of guesses, but they're just that, really. Keep in mind these numbers are two days old, and I took yesterday off.:)
I also will probably never find out, since architecture isn't really my bag; I need these numbers to compare against a different implementation of the same application using some of my stuff. As long as I can get the performance of my stuff to approach those numbers I reported, I'm happy.
HyperThreading is disabled in the Smithfield dual-core product too, so expect a mere 50% overall performance increase at the same clock speed (2.8GHz, 3GHz, 3.2GHz soon afterwards) for Intel.
I'm not sure what you mean, so I might be wrong. My understanding of what you said is that with HT enabled, you can expect a 50% performance increase. That is unfortunately not true. I'm part of a research group that's using P4s with HT, and the most realistic speedup you get is under 10%.
The problem with the chip is that eventhough two threads can have instructions executed simultaneously, they share everything. For example, if you run two floating point intensive applicaitons at the same time, they're both using the same floating point unit (units? I can't remember), which makes them basically sequential. Squeezing performance out of these is not easy.
I have some experimental numbers in front of me where on a 4 way SMP where each processor is a P4 with HT. The difference with a particular application is that going from one thread to four makes a difference from 16.0s to about 5.3s. But then going from four to eight (using all HT contexts in the machine) makes a difference of 5.3s to 5.1s.
If it's just having a conversation that impairs your driving, are we supposed to not speak with fellow passengers either?
When someone else is physically present, they are aware of what else is going on; they will make allowances for this in the conversation. It's naturally what we do.
Yesterday, for example, I was in a restraurant and there was a loud crashing noise from the kitchen. There was a group of guys at the table next to me, and one was talking. He paused for the sound, then resumed talking when it was over. Everyone understood what he said fine. It was an automatic thing.
If you're talking to someone on a cell phone in a car, they aren't aware, for example, if you're in heavy traffic and maybe they should let you focus on the driving. Compare car conversations to normal conversations the next chance you get.
From EE Times which someone else linked: "Duncan Stewart, a QSR scientist and the third author, performed most of the testing that demonstrated that the device actually works. The paper underwent rigorous peer review before being published."
Mass producable and all that stuff (which other people have brought up), maybe not, but if it can be made once, I'm confident it can be mass produced eventually.
And I don't recall reading any such claims anywhere. They just said we have this thing that has the same functionaity as a transistor which we've built and tested; it might be what's used in the future.
Slashdot Mirror
Caching, at all levels of computing, gives enormous performance gains. In the DNS world, without caching, everyone would hit top level domains which would introduce a serious bottleneck to what should be a distributed system.
Give me one good reason why TTL is useful.
It allows caching.
If you don't understand why that's an excellent reason or why it's useful, then you have an even poorer understanding of how DNS works and why it's around than I do, and I admit my understanding is rudimentary.
It is also not necessarily false.
Correct. But it's a critical assumption, and without it, the entire line of reasoning falls apart. Not stating that up front - as neither you or the author of the article did - either means you left it out on purpose, which is deceitful, or you left it out unintentionally, which means you have a fundamental misunderstanding of the issue at hand.
But where the numbers do make a difference - because there are more users, there are more hackers out there trying to find and exploit these holes so you will see an increase. I am sure that if the market share were reversed (I.E. having 8% or whatever the number is, and the rest going to FireFox) so would the numbers for flaws. Security through obscurity - the door swings both ways.
I understand your argument clearly; you don't need to restate it again. However, your argument still has the assumption that Firefox and IE have about the same number of flaws to be found. That is the only reasonable way for the the number of discovered flaws to exchange between the two if the market share was also exchanged. That assumption is not necessarily true.
More users = more amount of people finding flaws that already existed.
That's always been clear. However, when you try to apply that to Firefox, you're reversing the causality, which isn't necessarily true. That is, you're assuming that the less number of users is the cause for the less number of discovered flaws. It very well may be that there are less number of discovered (severe) flaws because Firefox is inherently more secure. If it is, then the discovery of severe flaws should be relatively independent of the number of users.
So the amount of time they are around is really not that much of an issue for our conversation.
Time itself wasn't really my focus, but the implication that something that's been around for a long time has been banged on pretty hard. The reason I brought up the fact that Unix and related technologies have been around longer than Windows is to address the argument the author made, and I felt you implied: Windows is used more than Linux, so it's okay that Windows has more discovered flaws. That argument implies that Linux has flaws sitting around waiting to be discovered (which I think is true), and that they probably have about the same number of flaws (which I don't think is true).
I talked above about why that argument is invalid. I brought up the issue of number of users and how long its been around to challenge the assumptions of the argument.
Hold on there.
Fact 1: Firefox hasn't shown that many security flaws in the past
Fact 2: it had fewer (95%?) using it then IE
Fact 3: those people using it were (mostly) more advanced then the typical IE/AOL user
Notice I left out two words: "because" and "and." Fact 1 is not necessarily caused by facts 2 and 3. That's a logical fallacy. There are other unmentioned facts which might actually be the cause of fact 1. Both you and the article's author made this logical fallacy.
the more people that use it [Linux], the more problems will come to light.
A point that you, and the article's author, overlook is that Windows is actually the new kid on the block, not Linux. While Linux itself has not been around as long as Windows, the technology Linux is based on (i.e., Unix and all related tools and platforms) have been around much longer than Windows. (In this context, when I say "Windows" I mean NT, 2000 and XP.) Furthermore, Linux and related Unix based OSes have been on the front line as servers far longer and in greater numbers than Windows has. So using the above fallacy for Linux breaks in two ways: it's not actually the new, underused one.
For the record, I am both a Linux and Windows user. I do most of my work on a Linux box at the office, but my home machine is Windows. I use Firefox on both, mainly because it has the best functionality.
True. I always thought there was nobility in failing a few classes in college. If you didn't fail a few, you weren't really pushing yourself hard enough. My transcript represented this worldview pretty well.
I don't understand how not pushing yourself follows from not failing a few classes.
I graduated with a BS in CS from Virginia Tech in 2003. There was no mention of using anything Apple in the department while I was there. In fact, they seemed to be strengthening their relationship with Microsoft through the MS Academic Alliance. Some classes required working on Linux, but most were on Windows.
Note: This has nothing to do with the big honking cluster of Apple machines. I'm talking about what faculty have on their desks, what it's in the labs, and what students are expected to work on.
Not really. I wrote something similar last week when I was trying to figure out how much extra memory valgrind needs to run a program. Linux eventually kills your program if you're using too much memory. In my case, "too much" was when I started asking for so much memory that I would be above the 4 gig limit.
If you really want to bring a system to a crawl, the best thing to do is figure out how much RAM it has. Request more memory than that so that the system is forced to swap pages to disk. Then do some memory intensive operations over all of the memory indefinitely. For example, a matrix multiplication inside a while(true) where the combined size of the matrices is larger than main memory should do it. This won't cause the system to crash, but it will be extremely slow since it's constantly doing disk I/O.
How does it compare with gprof? That's what I use, but not because I like it, but because it's there.
What AI ramifications?
We've been able to obtain truly random numbers for a long, long time. All you need to do is get information from some physical device - the Linux kernel has a random function that gets some random information from the keyboard. Sound cards work too.
But in most applications, a simple pseudo-random number generator is going to be indistinguishable from truly random numbers.
Right now, the Linux 2.4 kernel sees Pentium 4's with HyperThreading as two processors. The 2.6 kernel sort of sees them as two processors, but is aware that it's not the same as having two actual processors and does scheduling and load balancing a little differently (I think). Windows reports two processors, but I don't know if they've done anything special.
Dual core is different, but I think that this is basically what we'll see. The OS will report both cores as two distinct processors for most purposes, but when it comes to scheduling and load balancing, they'll probably take into account that it's not actually two processors. Since it seems CMP (Chim Multiprocessor; Intel and AMD are calling it dual core) and SMT (Symmetric Multithreading; Intel's implemenation is HyperThreading) are the direction processors are heading, operating systems will have to be aware of their architecture in order to take full advantage of them.
And this is an important point: they aren't two invdividual processors, and treating them as such can sometimes have drawbacks. (I know this is true with HT chips, and I think this will also be true for dual core chips.)
What CMP and SMT being on desktop machines might indicate is that multiprocessor machines (in general) might start to become the norm. And if that's true, then the practice of licensing software per CPU might no longer be valid.
Security experts in academia? I realize that some (a lot?) of them are more theoretical, but seems to be a good place to start. I know some research groups have been the ones to first report various security holes in software.
The difficulty with people in a VP position is there's no way of knowing if they have a technical background; I was part of a small startup company where our VP of engineering was also a primary developer, but it's not necessarily the case. My gut reaction is he's just presenting information that he thinks is in the best interest of the company - which, afterall, is his job.
Their expert is the Vice President of Threat Research at Webroot. That much is from the article. The article doesn't take the next logical step, however, and point out that Webroot is in the business of developing and selling software to prevent, detect and eleminate spyware. So it's certainly in this guy's interest for people to think that spyware is still a problem.
Their other expert is also from a company that makes similar software. So people who make anti-spyware software agree: you need anti-spyware software.
I'll be more concerned when independent parties think spyware in Firefox is an issue.
Considering that it's free, I don't think people have grounds to complain. In this case, and in others, they need to do extensive testing before it's non-Beta. How else can you do that without releasing it?
It's cheaper.
The chip makers have always been trying to squeeze more performance out of a chip. For the past ten years or so, upping the clock speed has been the easiest way to do that. Upping the clock speed is getting harder and the gains are smaller. So what they're trying to do is explore other ways of increasing the performance from a single chip. Right now, dual core looks like a better way of using the transistors on the chip.
No. That's a cluster, which is a different beast. Communication between nodes in a cluster requires message passing, usually over ethernet. Dual core is closer to SMPs, which means shared memory. Communicating via shared memory is faster.
Think about it this way. Let's say you and a friend are working on a math problem. An SMP is you both have your own sheet of paper, but you can read and write on his sheet of paper, and he can do the same to yours. A dual core is you both share the same piece of paper. A cluster if you both have seperate sheets of paper, and you can only communicate over the phone.
No, that will actually be just as bad as having two threads doing lots of floating point calculations. Codes with lots of branches make heavy use of the integer units. The most gain to be had is probably by having one thread that is compute bound and the other is I/O bound.
I really don't know. I can make lots of guesses, but they're just that, really. Keep in mind these numbers are two days old, and I took yesterday off. :)
I also will probably never find out, since architecture isn't really my bag; I need these numbers to compare against a different implementation of the same application using some of my stuff. As long as I can get the performance of my stuff to approach those numbers I reported, I'm happy.
Most CMPs designs have give them a seperate L1, but shared L2.
HyperThreading is disabled in the Smithfield dual-core product too, so expect a mere 50% overall performance increase at the same clock speed (2.8GHz, 3GHz, 3.2GHz soon afterwards) for Intel.
I'm not sure what you mean, so I might be wrong. My understanding of what you said is that with HT enabled, you can expect a 50% performance increase. That is unfortunately not true. I'm part of a research group that's using P4s with HT, and the most realistic speedup you get is under 10%.
The problem with the chip is that eventhough two threads can have instructions executed simultaneously, they share everything. For example, if you run two floating point intensive applicaitons at the same time, they're both using the same floating point unit (units? I can't remember), which makes them basically sequential. Squeezing performance out of these is not easy.
I have some experimental numbers in front of me where on a 4 way SMP where each processor is a P4 with HT. The difference with a particular application is that going from one thread to four makes a difference from 16.0s to about 5.3s. But then going from four to eight (using all HT contexts in the machine) makes a difference of 5.3s to 5.1s.
If it's just having a conversation that impairs your driving, are we supposed to not speak with fellow passengers either?
When someone else is physically present, they are aware of what else is going on; they will make allowances for this in the conversation. It's naturally what we do.
Yesterday, for example, I was in a restraurant and there was a loud crashing noise from the kitchen. There was a group of guys at the table next to me, and one was talking. He paused for the sound, then resumed talking when it was over. Everyone understood what he said fine. It was an automatic thing.
If you're talking to someone on a cell phone in a car, they aren't aware, for example, if you're in heavy traffic and maybe they should let you focus on the driving. Compare car conversations to normal conversations the next chance you get.
From EE Times which someone else linked: "Duncan Stewart, a QSR scientist and the third author, performed most of the testing that demonstrated that the device actually works. The paper underwent rigorous peer review before being published."
Mass producable and all that stuff (which other people have brought up), maybe not, but if it can be made once, I'm confident it can be mass produced eventually.
And I don't recall reading any such claims anywhere. They just said we have this thing that has the same functionaity as a transistor which we've built and tested; it might be what's used in the future.