Threading isn't parallelism, it's concurrency. They aren't the same thing.
A concurrent program is logically divided into several interacting threads. Concurrency is about the program's semantics, not its performance.
A parallel program is physically divided into several (not necessarily interacting) operations (usually threads, but might be vector ops) which run at the same time on different pieces of hardware. Parallelism is about the program's performance, not its semantics.
A web browser should be concurrent in that the network thread shouldn't block the Javascript thread shouldn't block the interface. It's less important that it be parallel, though this will improve performance and probably responsiveness when dealing with Javascript-intensive sites and flash movies.
A web server should usually be parallel for better performance. it's not particularly concurrent because its threads don't interact much.
It happens that writing a program concurrently makes it easier to parallelize, but it doesn't guarantee that it will be run in parallel. For example, Concurrent ML performs pretty well despite not supporting SMP.
I agree, but it's hard to say what standard auditors should be held to. Often, computer security audits are just surface level checks: they check your design docs and your testing methodology. And this is fine, but you get what you pay for. If a bug slips through your tests, or worse if you don't actually implement your design docs or tests, the auditors obviously shouldn't be liable. On the other hand, if there's a flaw that the auditors "should" have caught, and they don't, they should be liable at least to some degree.
The difficulty is that full, in-depth code audits are very, very hard. Consider the Linux kernel or OpenSSL: even after 16 years of "many eyes" treatment by engineers and security researchers across the world, serious bugs keep showing up. As a result, the fact that the auditor missed something doesn't mean much, and it's not clear that a court will be able to decide whether the auditor "should" have caught it.
I wonder if the same problem is present in other industries.
Steganography has the fatal flaw that the method has to remain secret. One basic rule of encryption is to assume the method is discernible and the security must be all in some secret key.
Not if you encode it in the sequence number. The sequence number is supposed to be a cryptographically strong random number, and if you replace it with part of an encrypted message, nobody should notice.
Strong links to well-researched hard mathematical problems.
This is usually only true for asymmetric (public-key) crypto. There are hash functions which are provably secure if some math problem is hard... pretty good math problems too (discrete log, not something "easier" like DDH).
But they're fabulously slow, not to mention they operate over prime-order fields instead of on bytes (this is a bigger problem for block ciphers than for hashes). We accept this slowness for public-key crypto because it seems to be required, and because only the header has to go through the public-key part. But every byte has to pass through the symmetric part.
There is an argument to be made that collision-resistance isn't that important (compared to a keyed version) and cryptographers should be willing to pay more for it. In this case, we'd use SHA-1 or MD5 for signatures and some other thing for fancier cases that actually require collision resistance.
My university experience is that in ginormous lecture classes (the kind with at least 100 students, usually for required courses), professors have no interaction with students other than lecturing them. In these classes, the TAs (often the prof's grad students) take the role of the prof, holding sections and office hours. Usually there was also a head TA who would take over for the prof in designing exams and shepherding the other TAs.
But in the higher-level classes, there would be fewer students. If there were 50 or fewer students in the class, answering questions in the lectures would be practical. If there were 30 or fewer students, the prof would hold his/her own office hours. The most fun classes were "grad-level" (in quotes because undergrads took them) discussion groups with 10 students or fewer. They worked like research groups almost as much as classes. Great times.
I wonder how this works at small colleges, actually. Since there are no grad students, you probably don't have as many advanced classes, right? Do you still have discussion-group style classes? Do they feel like research groups?
Three of my best profs lectured from yellowed notes. (Actually, two of them had notes on legal pads, so they started out yellow.) They didn't just read the notes, though... they just used them for formula reference. Two of them copied their yellowed notes to the blackboard while they talked, and the other one copied them to a pad of paper under a video cam so that people in TV land could see.
Two more of my best profs used transparencies with half the outline filled in, and would fill in the other half as they went.
I wonder what will happen when these profs catch up to the digital age, or rather, when it catches up to them...
Nautilus: Not sure what version this is, but in some recent version, if you clicked "clear history" in the "go" menu, with some low probability instead of the standard message it would say, "Are you sure you want to forget history?" and then in small text, "If you do, you will be doomed to repeat it."
Mac OS X: hold shift as you trigger expose, open a folder or dock a window. The animation plays in slow motion.
SSH: if your/etc/password is munged (the local one, not the one on the server), then the ssh client will tell you "You don't exist, go away!"
What makes you think he didn't take aspirin? It's a perfectly reasonable drug to take for a headache. There's a big jar in my medicine cabinet, right next to the ibuprofen...
The obvious implication of this exploit, if SMM is truly more privileged than the hypervisor, is to escalate from root on one vm to root on other vms on the same box. That could be pretty devastating, both for hosting providers and security researchers.
On another note, I know nobody RTFA around here, but ya gotta love this quote:
Intel feels that it has a solution in SMM transfer monitor (STM). The premise is that STM places SMM in a sandbox as Intel explains further:
Lock-based synchronization has known pitfalls: using locks for fine-grain synchronization and composing code that already uses locks are both difficult and prone to deadlock. Transactional memory is proposed to simplify parallel programming by supporting âoeatomicâ and âoeisolatedâ execution of user-specified tasks.
Gotta love acronym confusion! (That second paragraph is describing Software Transactional Memory, which is totally unrelated to the proposed SMM Transfer Monitor.)
As for having only doubles, that is true for the language, but not for engines, which can implement an integer type as well.
True enough. But the fundamental problem remains: the more information is available statically, the better you can compile it. Javascript has relatively little information available statically, and so is hard to compile.
Why have you assumed the javascript user ran the site for 5 hours a day for a week, but that the installed.exe user ran it for a year?
Because user attention is a scarce resource. If the user has to open your application for it to run, it will not run as often.
And are you sure that modern browsers on multicore machines don't let multiple JS threads run on different cores?
No, although with the exception of Safari 4, no browser with worker threads is even out of beta.
In which case, I would find it easy to believe that for every one slashdotter who would install a distributed computing node, there would be at least 500 who would leave a/. window open while they're at work (and possibly have another one open at work).
Perhaps for a while, but I think the novelty of this would wear off quickly. Like I said, attention is a scarce resource.
More or less, yes. If both types of resources are abundant, and X resources are more efficient to use, then there's no reason to use Y resources... just focus your effort on getting more X resources. This is why most groups just run their stuff on a cluster, rather than dealing with the development, hosting, marketing and distribution of a folding@home type project.
If a user downloads, say, folding@home, it's running all day, every day, on all cores of the machine, whenever the computer is on and idle, which is most of the time. The user doesn't have to remember to run it, doesn't have to devote screen real estate, attention and so on, and the program is less annoying because of its low priority and relatively low memory footprint (less boxing).
Additionally, the 40x I cited was in the fastest available browser (Chrome), compared to a relatively slow implementation (OpenSSL), for code that doesn't benefit from vectorization (at least, not on x86-based processors). I expect that the difference between a scientific compute kernel in JS and in assembly would be at least 100x, maybe 200x or more.
Let's suppose that everyone in your rosy world uses FF 3.1 with JIT. That's 3-5x slower than Chrome in my benchmarks; say 4x. Let's suppose that Chrome is 25x slower than unvectorized C, which is 4x slower than optimized assembly. Let's say people run the site 5 hours a day on one core for a week, but have their dual-core computers on for 10 hours a day, 90% idle and would keep folding@home installed for a year.
Then the EXE is 4 * 25 * 4 * 2 * 2 * 50 * 0.9 = 72000x more productive.
I don't use noscript. However, I dislike most flash- and javascript-based UIs. They're often heavy and unintuitive, and they usually break the back button, deep linking and "open in a new tab".
What's more, javascript-intensive UIs are terrible for the disabled, for scripts, for search engines, and often for mobile devices as well.
That's not to say that Javascript is useless, or even Flash. They have their place in web design, but they do give designers an awful lot of rope.
Actually it was the '90s, but whatever. The thing is, non-DHTML web pages are actually pretty good for most things... what made those early '90s web pages so awful was no CSS, slow connections, and the fact that people really didn't know how to design for this new medium.
Probably 99% of the web still shouldn't need Javascript or flash, though pages usually do need to be dynamic on the server side.
Javascript really isn't suited for this kind of thing, even with worker threads, for two reasons I can think of. First, web clients are transient... they'd have to report back often in case the user clicks away.
But more importantly, Javascript just isn't a good language for massive computation. It only supports one kind of number (double), has no vectorization or multicore capabilities, has no unboxed arrays, and even for basically scalar code is some 40x slower than C, let alone optimized ASM compute kernels. (This is for crypto on Google Chrome. Other browsers are considerably slower on this benchmark. YMMV.)
The power consumption numbers in TFA are totally useless as applied to netbooks. My laptop (an ultraportable, not a netbook... it has a 1.6 GHz Core 2 Duo in it) uses maybe 25 watts at full load, and maybe 8-9 watts at idle, counting the screen and wireless (that's in Windows; Linux uses slightly more power for some reason).
TFA quotes one system at 48 watts and the other at 68 watts under load. You can't say that this is representative of their performance in a netbook.
The real question is, if you compare them with chipsets, clock speed, voltages, hardware, power management strategies etc that are suitable for a netbook, how is the power consumption and performance? TFA doesn't address that, so it's basically useless.
Also, remember that the two power figures of merit for a netbook are idle power and joules per operation. Suppose that procs A and B are the same at idle, and that B uses twice as much extra power under load than A, but is twice as fast. Then B wins almost no matter what you're doing (yadda cooling yadda voltage ramp yadda yadda).
Slashdot Mirror
Threading isn't parallelism, it's concurrency. They aren't the same thing.
A concurrent program is logically divided into several interacting threads. Concurrency is about the program's semantics, not its performance.
A parallel program is physically divided into several (not necessarily interacting) operations (usually threads, but might be vector ops) which run at the same time on different pieces of hardware. Parallelism is about the program's performance, not its semantics.
A web browser should be concurrent in that the network thread shouldn't block the Javascript thread shouldn't block the interface. It's less important that it be parallel, though this will improve performance and probably responsiveness when dealing with Javascript-intensive sites and flash movies.
A web server should usually be parallel for better performance. it's not particularly concurrent because its threads don't interact much.
It happens that writing a program concurrently makes it easier to parallelize, but it doesn't guarantee that it will be run in parallel. For example, Concurrent ML performs pretty well despite not supporting SMP.
I agree, but it's hard to say what standard auditors should be held to. Often, computer security audits are just surface level checks: they check your design docs and your testing methodology. And this is fine, but you get what you pay for. If a bug slips through your tests, or worse if you don't actually implement your design docs or tests, the auditors obviously shouldn't be liable. On the other hand, if there's a flaw that the auditors "should" have caught, and they don't, they should be liable at least to some degree.
The difficulty is that full, in-depth code audits are very, very hard. Consider the Linux kernel or OpenSSL: even after 16 years of "many eyes" treatment by engineers and security researchers across the world, serious bugs keep showing up. As a result, the fact that the auditor missed something doesn't mean much, and it's not clear that a court will be able to decide whether the auditor "should" have caught it.
I wonder if the same problem is present in other industries.
I'll pay them 8.25% of what I paid for the song.
"My kingdom is not of this world" indeed...
Steganography has the fatal flaw that the method has to remain secret. One basic rule of encryption is to assume the method is discernible and
the security must be all in some secret key.
Not if you encode it in the sequence number. The sequence number is supposed to be a cryptographically strong random number, and if you replace it with part of an encrypted message, nobody should notice.
Probably not. I don't think it says enough about the distribution of the primes to make either finding primes or factoring semiprimes easier.
Strong links to well-researched hard mathematical problems.
This is usually only true for asymmetric (public-key) crypto. There are hash functions which are provably secure if some math problem is hard... pretty good math problems too (discrete log, not something "easier" like DDH).
But they're fabulously slow, not to mention they operate over prime-order fields instead of on bytes (this is a bigger problem for block ciphers than for hashes). We accept this slowness for public-key crypto because it seems to be required, and because only the header has to go through the public-key part. But every byte has to pass through the symmetric part.
There is an argument to be made that collision-resistance isn't that important (compared to a keyed version) and cryptographers should be willing to pay more for it. In this case, we'd use SHA-1 or MD5 for signatures and some other thing for fancier cases that actually require collision resistance.
My university experience is that in ginormous lecture classes (the kind with at least 100 students, usually for required courses), professors have no interaction with students other than lecturing them. In these classes, the TAs (often the prof's grad students) take the role of the prof, holding sections and office hours. Usually there was also a head TA who would take over for the prof in designing exams and shepherding the other TAs.
But in the higher-level classes, there would be fewer students. If there were 50 or fewer students in the class, answering questions in the lectures would be practical. If there were 30 or fewer students, the prof would hold his/her own office hours. The most fun classes were "grad-level" (in quotes because undergrads took them) discussion groups with 10 students or fewer. They worked like research groups almost as much as classes. Great times.
I wonder how this works at small colleges, actually. Since there are no grad students, you probably don't have as many advanced classes, right? Do you still have discussion-group style classes? Do they feel like research groups?
Three of my best profs lectured from yellowed notes. (Actually, two of them had notes on legal pads, so they started out yellow.) They didn't just read the notes, though... they just used them for formula reference. Two of them copied their yellowed notes to the blackboard while they talked, and the other one copied them to a pad of paper under a video cam so that people in TV land could see.
Two more of my best profs used transparencies with half the outline filled in, and would fill in the other half as they went.
I wonder what will happen when these profs catch up to the digital age, or rather, when it catches up to them...
I dunno if this qualifies as fair use. It has a severe impact on the potential market for the work being copied :-)
Nautilus: Not sure what version this is, but in some recent version, if you clicked "clear history" in the "go" menu, with some low probability instead of the standard message it would say, "Are you sure you want to forget history?" and then in small text, "If you do, you will be doomed to repeat it."
Mac OS X: hold shift as you trigger expose, open a folder or dock a window. The animation plays in slow motion.
SSH: if your /etc/password is munged (the local one, not the one on the server), then the ssh client will tell you "You don't exist, go away!"
What makes you think he didn't take aspirin? It's a perfectly reasonable drug to take for a headache. There's a big jar in my medicine cabinet, right next to the ibuprofen...
What the fuck?!?! I told you never to come back here again!
The obvious implication of this exploit, if SMM is truly more privileged than the hypervisor, is to escalate from root on one vm to root on other vms on the same box. That could be pretty devastating, both for hosting providers and security researchers.
On another note, I know nobody RTFA around here, but ya gotta love this quote:
Intel feels that it has a solution in SMM transfer monitor (STM). The premise is that STM places SMM in a sandbox as Intel explains further:
Lock-based synchronization has known pitfalls: using locks for fine-grain synchronization and composing code that already uses locks are both difficult and prone to deadlock. Transactional memory is proposed to simplify parallel programming by supporting âoeatomicâ and âoeisolatedâ execution of user-specified tasks.
Gotta love acronym confusion! (That second paragraph is describing Software Transactional Memory, which is totally unrelated to the proposed SMM Transfer Monitor.)
As for having only doubles, that is true for the language, but not for engines, which can implement an integer type as well.
True enough. But the fundamental problem remains: the more information is available statically, the better you can compile it. Javascript has relatively little information available statically, and so is hard to compile.
Why have you assumed the javascript user ran the site for 5 hours a day for a week, but that the installed .exe user ran it for a year?
Because user attention is a scarce resource. If the user has to open your application for it to run, it will not run as often.
And are you sure that modern browsers on multicore machines don't let multiple JS threads run on different cores?
No, although with the exception of Safari 4, no browser with worker threads is even out of beta.
In which case, I would find it easy to believe that for every one slashdotter who would install a distributed computing node, there would be at least 500 who would leave a /. window open while they're at work (and possibly have another one open at work).
Perhaps for a while, but I think the novelty of this would wear off quickly. Like I said, attention is a scarce resource.
More or less, yes. If both types of resources are abundant, and X resources are more efficient to use, then there's no reason to use Y resources... just focus your effort on getting more X resources. This is why most groups just run their stuff on a cluster, rather than dealing with the development, hosting, marketing and distribution of a folding@home type project.
It would need to be 10000x at the very minimum.
If a user downloads, say, folding@home, it's running all day, every day, on all cores of the machine, whenever the computer is on and idle, which is most of the time. The user doesn't have to remember to run it, doesn't have to devote screen real estate, attention and so on, and the program is less annoying because of its low priority and relatively low memory footprint (less boxing).
Additionally, the 40x I cited was in the fastest available browser (Chrome), compared to a relatively slow implementation (OpenSSL), for code that doesn't benefit from vectorization (at least, not on x86-based processors). I expect that the difference between a scientific compute kernel in JS and in assembly would be at least 100x, maybe 200x or more.
Let's suppose that everyone in your rosy world uses FF 3.1 with JIT. That's 3-5x slower than Chrome in my benchmarks; say 4x. Let's suppose that Chrome is 25x slower than unvectorized C, which is 4x slower than optimized assembly. Let's say people run the site 5 hours a day on one core for a week, but have their dual-core computers on for 10 hours a day, 90% idle and would keep folding@home installed for a year.
Then the EXE is 4 * 25 * 4 * 2 * 2 * 50 * 0.9 = 72000x more productive.
Use the right tool for the job.
I don't use noscript. However, I dislike most flash- and javascript-based UIs. They're often heavy and unintuitive, and they usually break the back button, deep linking and "open in a new tab".
What's more, javascript-intensive UIs are terrible for the disabled, for scripts, for search engines, and often for mobile devices as well.
That's not to say that Javascript is useless, or even Flash. They have their place in web design, but they do give designers an awful lot of rope.
Actually it was the '90s, but whatever. The thing is, non-DHTML web pages are actually pretty good for most things... what made those early '90s web pages so awful was no CSS, slow connections, and the fact that people really didn't know how to design for this new medium.
Probably 99% of the web still shouldn't need Javascript or flash, though pages usually do need to be dynamic on the server side.
Javascript really isn't suited for this kind of thing, even with worker threads, for two reasons I can think of. First, web clients are transient... they'd have to report back often in case the user clicks away.
But more importantly, Javascript just isn't a good language for massive computation. It only supports one kind of number (double), has no vectorization or multicore capabilities, has no unboxed arrays, and even for basically scalar code is some 40x slower than C, let alone optimized ASM compute kernels. (This is for crypto on Google Chrome. Other browsers are considerably slower on this benchmark. YMMV.)
Nonsense. Everyone knows that (in Ireland at least) the worst drivers are Polish.
So, if I remember my stats correctly, that means there's a 95% chance the real result is between 94% and 104%?
Parent is joking, but this is because +- 5% is accurate to first order and no more. (Also, confidence and chance are different things, but whatever.)
The power consumption numbers in TFA are totally useless as applied to netbooks. My laptop (an ultraportable, not a netbook... it has a 1.6 GHz Core 2 Duo in it) uses maybe 25 watts at full load, and maybe 8-9 watts at idle, counting the screen and wireless (that's in Windows; Linux uses slightly more power for some reason).
TFA quotes one system at 48 watts and the other at 68 watts under load. You can't say that this is representative of their performance in a netbook.
The real question is, if you compare them with chipsets, clock speed, voltages, hardware, power management strategies etc that are suitable for a netbook, how is the power consumption and performance? TFA doesn't address that, so it's basically useless.
Also, remember that the two power figures of merit for a netbook are idle power and joules per operation. Suppose that procs A and B are the same at idle, and that B uses twice as much extra power under load than A, but is twice as fast. Then B wins almost no matter what you're doing (yadda cooling yadda voltage ramp yadda yadda).
VW bugs are a unit of mass.