First, kill anything that would be stressing the video card. I really don't know how to prioritize this, or even to get any sort of report on what's using my video card, how much RAM, how many pipelines, etc. For now, it should still be pretty easy. If Flash starts getting hardware accelerated, flash ads in your browser will lag you horribly.
Next, find any task that's using CPU and renice it down:
renice 40 -p `pidof a_huge_app`
And finally, play your movie at the highest priority:
sudo nice -n -20 mplayer -cache 102400 foo.mp4
There's probably a GUI somewhere for doing something similar. Point is, I've gotten CPU prioritization to work reasonably well -- I suppose YMMV? -- and I don't care much about IO prioritization when I've stuck a 100 meg buffer in front of it, especially as any OS or filesystem that can handle that much traffic in the first place should serve my process in a reasonable amount of time.
Then again, maybe that last point is mostly because I've got a RAID-0 system at home.
Disclaimer before I begin: When I say "core", I really mean "core and/or CPU". I mean this because multiple CPUs do still have cores, so calling a multi-CPU system "multicore" isn't that innaccurate, whereas calling a dual-core system "multi-CPU" is wrong. Also, "core" sounds better than "CPU".
I did mention single tasks & data being processed by multiple threads, as well as 'coarse multithreading'
Also not the same thing as pervasive message passing.
& prior to yourself.
If you want to play the "me first" game, I mentioned Erlang before you entered this thread. Erlang takes the model you describe to an extreme -- a well-designed Erlang system could have hundreds, or thousands, of "processes", all of which communicate via message-passing alone. And note again, this is orthogonal to what you describe -- you may or may not be using message passing to do what you do, and an Erlang program may or may not be operating on the same data, or even somewhat "shared" data -- although Erlang would tend to encourage sharing less rather than more, when appropriate.
I should note also that I mentioned Erlang with the assumption that anyone interested would look it up (apparently you didn't), and with the full knowledge of what an Erlang-like system does. And I should also note that even in an Erlang program, it's possible your app doesn't scale as well as you think it does, and it's even possible you'll get some unexpected synchronous-ness, although I admit that is rare. But it's also hard to test for without actually running it on a multicore system.
I.E. -> The more CPU cores you have, the more of these backgrounded apps like services OR trayicon minimized apps (multiple threads (or not)) you can run across said cores!
And if they're not CPU-intensive, what's the point, honestly? If they're not CPU-intensive, they don't need to be threaded at all, just shove them all to an unused core; they probably won't fill it.
If you're not running anything CPU-intensive, hey, a single-core system still has a mostly-unused core. If you're running one thing that's CPU-intensive, shove them to that second core, which is in line with what I keep saying: Dual-core is fine and useful, but more than two isn't going to do much, most of the time.
(& thus, you'd be able to run more of them @ once due to the presence of multiple CPU cores (or, physical CPU's present, such as a true "SMP" rig has) & SMOOTHLY
Maybe "not CPU-intensive" isn't sinking in.
Right now, I'm on a laptop -- dual-core, 2ghz. I have 158 processes running. My system hasn't had more than 5% CPU used, and generally less than two. These processes include things like MySQL (just in case I want to do some Rails development, even though I'm using SQLite, but I haven't disabled MySQL yet), Kopete (for IM), ssh, Konqueror with, oh, eight tabs, Firefox with four tabs (all Google apps), a few virtual-machine related stuff (DHCP server, virtual switch, etc) in case I should want to fire up an XP machine, and so on.
Oh hey, and there's a Rails console sitting open... and four other Konsole windows I'd forgotten about on another desktop. Some of it might even be swapped out by now.
And it all still uses less than 5%. If we assume that's distributed fairly, and we take the 5% number (which is generous; it's more like 2%), it'd still be less than 10%.
E.G.-> There is NOTHING stopping the OS' process scheduler subsystem from sending single thread designed apps to the 2-N cpu cores present either, mind you.
Except a distinct lack of 2-N single-threaded apps needing to use a significant amount of CPU on a typical desktop. That was my point.
Go back to my original post, where I mention raytracing and make -jN. Povray isn't threaded itself; I'd have to run more than one of them, but I'm sure, given a big enough ani
its not ssh overhead its synchronous block encryption cpu usage.
Out of curiosity, is this still a limiting factor if top doesn't show CPU usage at 100%?
I mean, am I doing it wrong? I'm not the original poster, but look here:
david@worf:~$ dd if=/dev/urandom of=foo bs=1M count=100
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 18.873 seconds, 5.6 MB/s
david@worf:~$ scp foo localhost:~/foo.2
foo 100% 100MB 33.3MB/s 00:03
david@worf:~$
(Whitespace truncated to fool lameness filter.)
Am I doing something wrong? I mean, this is a fast laptop, but still. Let me make the naive assumption that 64-bit is twice as fast as 32-bit, and 2 cores are twice as fast as 1. I got 33.3 MB/s on a dual-2ghz 64-bit processor, so we're pretending that's equivalent to an 8 ghz single-core 32-bit processor.
That means an 800 mhz, 32-bit machine should still be able to do 3.3 MB/s. By the same logic, at 80 mhz, you can do 300 KB/s, and at 40 mhz, you can still beat 150 KB/s, which is still faster than 124.6 KB/s.
Those are a lot of naive assumptions, both ways. In fact, it's ludicrously un-scientific, without being able to test against an actual server. (And besides, if I was needing to test bandwidth, I'd probably use netcat instead, on a random port, with some random data.) I'd also be curious to run both tests from other places.
But based on that, and on my experience with scp, I'd say that if you're getting less than about a meg per second on anything made in the last five years, scp isn't the limiting factor. That's a megabyte.
I'm going to tread very lightly here, as I do not want to become a Rails fanboy.
That said, the two languages that were most useful for me at my current job are Ruby and Javascript. Ruby for Rails, and Javascript for HDi (before HD-DVD died). For the HD-DVD stuff, I had to use Visual Studio occasionally, but just look how useful my HDi skills are now... For the Rails stuff, I run Linux. Two of my co-workers run Windows, one runs OS X. The OS X guy uses TextMate, the Windows guys use Eclipse/Aptana (I think), and I haven't touched Visual Studio since the HDi stuff.
So it may not be easy (or even possible) to avoid ever seeing the MS tools, but "real businesses" use the right tool for the job -- or at least, what they think is the right tool for the job. It is possible to find an MS shop and never leave Visual Studio. It is also possible that you'll never touch Visual Studio.
I'm allowed to use whatever tools make me the most productive. Out of habit, that's vim and bash right now, but your mileage may vary -- a lot. What you already know has a big impact (I knew vim), and if you don't know anything (you're in school), you should be exposed to everything.
In particular, did you learn any Lisp/Scheme in school? What about Haskell? Or Erlang, or Smalltalk/Squeak? If not, you owe it to yourself to learn these now, even if you'll never use them at work. They will force you to think in different ways, and you'll come away with skills that apply to any language.
That sounds great, as long as you provide the other side of it, too.
For instance, say I paid for 6 mbits. Boost me to 100 mbits if you like for the first few seconds, but after that, give me my 6 mbits.
I don't have a problem with Comcast "cheating" in this way. My problem is that you don't even get those 6 mbits you paid for ("unlimited" or not), you get "However much Comcast thinks you deserve" before they ban you for a year.
The "Captain Obvious" comment was in response to a statement which is always true. If an OS couldn't send additional tasks to another CPU, there would be no point to multicore at all, would there?
It's a bit like saying "A multitasking OS lets you run multiple tasks at once. You no longer have to stop one task to start another."
Funny, mine don't, & I've been building multiple thread bearing coded apps since 1997.
Good for you.
I've been saying THAT, the whole time here & MANY TIMES NOW!
No, you've been saying "coarse multithreaded", which is a bit different than pervasive message-passing.
Aha! So, you DO admit there is a gain...
Never said there wasn't. How is "there is a gain" inconsistent with "it's completely unnecessary"?
Ok, consider this then - what about all the applications in the way of say, backgrounded services &/or trayicon'd minimized apps you could run, & more smoothly, doing your normal workload as well alongside they, IF you have them coded with multiple thread design & with dual (or more) cores (or, physical CPU's in "True SMP")?
I'm sorry, I'm really having difficulty parsing this one. Correct me if I read you wrong:
Do you mean background processes which are multithreaded and CPU intensive? That's what it looks like... But what does the system tray (or minimization) have to do with that?
If so, then I simply haven't seen many of these. Partly due to this "coarse multithreading" design that is so pervasive, partly due to things like global interpreter locks creeping in where people don't expect them, and mostly due to the fact that I simply don't have that many CPU-intensive background tasks I want to run in the first place, threaded or not.
And if they were written to scale properly, it would actually, in some circumstances, make things worse -- if a video encode can use 100% of 4 cores on a quad-core system, I have to prioritize it down, just as if it was using 100% of 1 core on a single-core system. Where multicore is providing the biggest perceptual gain right now is laziness -- I fire off one background video encode that can only saturate 1 core, maybe spill over a few minor IO threads and such and use 2% of the other core, and I still have most of a core free for anything interactive.
I realize the technological differences. But I think you see the philosophical implications here:
It may be possible to wire FTP servers together, by putting HTML pages on them, but I have no idea how current browsers would react. The Web is no more intrinsically connected -- in fact, there are a number of services which run over HTTP which aren't even particularly well connected internally, let alone to other servers.
So, on that level, the Web is less of a "network" than Gnutella is.
BitTorrent, while it is self-contained, is also every bit as much a "network" as the Web is. It's this way before even hitting the torrent file; I can Google for torrent sites, and some will link to others. At a lower level, there is actually a decentralized network built on top of BitTorrent, called DHT (Distributed HashTable), and even without that, one can add any tracers which are serving the same collection of files.
From a user interface perspective and from a censorship perspective, it's really no worse than Gnutella.
There's no clear signpost as to what's the "right" distro for beginners(UBUNTU UBUNTU UBUNTU, but newbies won't know that
Really?
I don't even talk about Linux anymore, I talk about Ubuntu. (Now I can piss off both RMS and Linus!) Which distro does Dell pre-load and provide support for? Ubuntu. Why are we even having this discussion?
XP was the standard for Windows for 5 or 6 years, and it went through 2 major revisions in that time. OS X revs approximately every 18 months, and is on the fifth version to ship since 2000. You're not treated like you're stupid by the community for getting frustrated with the shortcomings of OS X 10.2.
Because upgrading to 10.5 is neither free nor necessarily foolproof, or even an improvement. If you've been tracking Ubuntu, it's usually going to be a pretty gentle upgrade every six months, and it's as free as your Internet connection.
Similarly, the barrage of choice that assaults users of linux systems is a detriment to the newbie. Having to pick window managers in 2008 is a disgrace.
Then you just install Ubuntu. Yes, Kubuntu et al are out there, but it's very clear what the default is.
Also, what's the alternative? You want a Macbook, a Macbook Pro, a Macbook Air? In black or white? Glossy or matte?
You want Windows Vista... I guess that's Home Basic? Home Premium? Media Center? Ultimate? Or just XP Pro, because you hear Vista sucks? 64-bit?
The decision should be out of the end user's hands until he wants to make the choice, at which time it should be available to him.
Once again -- Ubuntu from Dell. Or the KDE-based thing that the EEE PC comes with. The choice is always there for you to find (apt-get install kubuntu-desktop), and it's only there if you look for it.
Anyone who Googles for advice is going to get a bunch of choices rammed down their throat anyway, no matter what they choose.
While I don't find the alternatives good (and I used pidgin about a month ago)
Kopete is damned good. But it doesn't have a Windows port.
I doubt foobar2000 can keep the global hotkeys i use, or the popupplus window that transparently slides out from the side of my screen on track change
Amarok can do both of the things that you mention. It's not Foobar2000, but what is it missing that Foobar has?
or anything else more advanced than simple screen drawing that isn't a game.
Except that quite a few good games do work. I keep an XP partition anyway, but I'm hardly dependent on it.
all good linux software runs on windows(usually natively), yet not all good windows software runs on linux (even when you include emulation)
Not true, actually. It may be that the only Linux software you've heard of runs on Windows, but that certainly doesn't imply that all good Linux software runs on Windows. Like Kopete, above.
Or, in other words, you win some, you lose some.
(Another random example: Ruby on Rails. You can develop on Windows if you like. It's not going to deploy easily (with Capistrano) to anything that's not vaguely Unix.)
Or in the alternate reality where a virtual PC (vmware etc) has hardware 3D.
Give it a year. There's already support for OpenGL on Windows via VirtualBox, and if you're running a VM on a Mac with hardware acceleration, keep in mind that Parallels is pretty much using Wine's Direct3D wrappers.
When Linux is INTEGRATED and works RIGHT, NOW, as in OUT-OF-THE-FUCKING-BOX, then I'll use it again.
Welcome to Ubuntu.
Unless, of course, you're holding it to a higher standard of OUT-OF-THE-FUCKING-BOX-ness than your Mac, which didn't come with Photoshop, did it?
BitTorrent, as implemented today, is also relatively decentralized. No one torrent is, but BitTorrent itself is as decentralized as the Web -- anyone can throw up a tracker, or put a torrent on an existing tracker and seed.
Long answer: The advantage is that the single CPU-intensive thread can use an entire core, instead of having to share it with other things that might be running on your system. Except that these other tasks probably aren't using a significant portion of your CPU.
The other advantage, which I think I said in my original post, is that you don't have to worry about prioritization, at least not by yourself. No single CPU-intensive task is going to saturate your entire system. It'll fill one core, and you'll have a whole other core to play with. With a single-core system, you'd have to make sure that CPU-intensive task runs at a low priority if you want your system to be usable for anything else.
Of course, if you're insane, you can always run more than one of those CPU intensive tasks.
In my case, it was a no-brainer. I had a single-core system at 1.8 ghz, which I occasionally overclocked until I found out that it really was unstable at 2.4 ghz. Now I have a dual-2.4 ghz system.
If the computation was going to take a week, I can always drop the priority down and play games anyway, unless I don't have enough RAM. If I play games for a few hours a day, it might mean the week-long computation takes an extra day or so, and does that really matter so much?
I never said it did - I only said the OS' of today's process scheduling components can & WILL send other threads to the least used CPU if one of the CPU's/cores gets "saturated" (all cycles used up).
Thank you, Captain Obvious.
On this note? On a single core system, multithreaded code actually has MORE OVERHEADS than single threaded code does, so you know.
Which makes systems designed this way all the more interesting when they fall apart on a multicore system.
Where you "gain", is under multitasking scenarios, the most - the OS process scheduler sees to it with multithreaded code, sending threads to the least used core, as is needed (usually IF the main core gets saturated, such as you note with this Amarok tool/game you use). Again, imo? This helps MOST, while multitasking diff. apps...
A side note: Amarok is a music player. It has absolutely no excuse to use any amount of CPU at all. That was a bug.
In other words, it helps when:
You don't want to deal with setting priorities. I have both my cores saturated now with povray processes, but my system is still perfectly responsive and feels just as fast, as I've set both of those processes at a low priority. It would be roughly the same on a single core. Even with Amarok.
You're actually doing something like rendering a couple of povray videos.
Well, doing "coarse multithreading" (splitting up discrete separate tasks & data onto separate threads) is not that bad
Remember that we're talking about Quake 3. If you split it up into nice, neat, "coarse" tasks, you might gain 5% or so over no mutithreading at all -- and maybe lose 5% on the single-core system. I think he did eventually manage to make it work well, but it was not easy.
This comes from the fact that even "coarse multithreading" isn't always easy. If you're using locks and semaphores, I'd argue that any sort of multithreading which must share data -- in Quake3, you're going to need to do culling, AI, physics, etc, all on the same model of the game world -- if you do that with locks and semaphores, it is probably one of the hardest problems in computer science. If you do it with message passing, it gets significantly easier, but it's still possible to have deadlocks, even in a pure message-passing system.
So, in most cases, you've got one core which is doing most of the game, and is saturated or close to it, and the other core is doing audio, compression, network, your standard antivirus, system tray apps, etc, and is at maybe 50%, if you're lucky. So dual-core does help, but three is pretty useless, unless you want to also be doing video encoding, raytracing, etc.
& again: On a single-core rig, multithreaded code actually has MORE overheads.
Are you sure? Played with Hyperthreading much?
Even if this is always true, it's also not necessarily relevant. Multicore systems are getting cheaper, so while it doesn't seem like a must-have to me as a consumer, I absolutely want to target them as a programmer. The classic example that I deal with at work now is, we use Ruby on Rails. The next version of the Ruby interpreter might offer as much as a 3x speedup, and even then, it's significantly slower than, oh, Java. But scalability is more important than performance -- this app runs on Amazon EC2, and if I need to, I can fire up another 20 or so servers, stick a load balancer in front of them, and we'll be able to utilize all of that.
So, sure, Rails is slower than some other solutions, but it's also very scalable, when done right.
(The real irony in that example is that Rails itself is not thread-safe, and that even if it were, Ruby has a global interpreter lock, so it could not utilize more than one core. This is resolved by running more than one Rails process on a single machine and putting a load balancer in front
And the phone company having already laid cable did not prevent the cable company from doing it again.
There's no point. The phone lines can't carry cable signals.
The government prevents other companies to lay additional physical lines. It's illegal to do so. It's illegal to compete.
Oh, I get it.
Your idealist Libertarian future involves another physical line for each possible competitor? Not only raising the barrier of entry, but wasting resources and trashing the environment, too?
It's disgusting even when you consider that it won't work.
I use Linux, and yes, I'm pretty sure. Note that I said "more than dual-core", not "more than a single-core".
Also, simply having more than one thread doesn't necessarily mean it scales to multiple cores. Look at the big scripting languages -- I'm not sure about PHP, but I can say that Perl is at least honest about using green threads, and while Ruby and Python use OS threads, they each have their own variant of a global interpreter lock, meaning that effectively, only one thread can be running a script at a time. I'm sure there are many systems designed like that -- naively "multithreaded", run fine on a single core, but either won't fully utilize a second core, or will actually start crashing.
Regarding your example, let's see... Spreadsheets? Really? Throw it on a single-core, 3 ghz, it'll be fast enough. If not, it's doing something that spreadsheets were never designed to do. Again, dual-core might help, but I really don't see more than that being useful -- not because Excel is necessarily not threaded, but because it couldn't find anything reasonable to do with that extra power.
Or a game -- fine, audio in one thread. Audio that uses maybe 0.5% of the CPU. Networking -- what, 1%? And so on... Games are also the least likely to use languages that scale naturally (like Erlang), because for a long time, they've been programmed in languages like C and C++, trying to squeeze every last ounce of performance out of a single core. The story goes that when John Carmack got a dual-core system (or was it dual-processor?), he tried to make Quake3 multithreaded. In his first attempt, he made it slower than it was single-threaded.
The video itself doesn't necessarily use all of a single core. But even if it does, you still have one more.
There is multithreaded h.264, but it requires that the video was encoded that way, and there's a slight loss in quality (or bit efficiency). This is because, if I understand it, the way multithreaded h.264 works is, it slices the video up, physically. Imagine a vertical bar down your 1080p display -- everything on the left is one thread, everything on the right is the other.
I think it's nice that this kind of thing is supported, in case it's ever useful -- particularly in much higher-resolution video -- but right now, I don't see it being particularly helpful. And again, a lot of the gain is in not having to set thread priority -- if I'm encoding, I generally don't care how long it will take, so I could just set that to the lowest possible priority, and watch all the video I want, even on a single core.
Now, I know how I could fill a quad-core, but none of the uses I can think of really have much everyday utility to me, at least until games start using them properly.
I think you got it with that link, but just in case...
The green threads are a necessity, as most native OS threads won't handle the sheer number of Erlang "processes" that might be running.
But you can specify an arbitrary number of "real" threads to load-balance the green threads against.
Erlang also has ludicrously easy (and insecure) "native" RPC, so it scales easily to a cluster of (trusted) computers. It also has reasonably easy socket programming, but it's generally not as good as the native RPC, when it's an option.
Last I checked, they not only had long latencies, they also had horrifically slow upload speeds and possibly some throttling/metering of their own. But I live in an area with decent options, so I don't really know.
In any case, you've just illustrated two important points:
The barrier of entry is still pretty high. How many small companies do you know who can afford their own satellites?
Even if you consider four possibilities (three satellite and one DSL) to be competition, there's still no competition if the GP wants a reasonably low-latency connection.
Slashdot Mirror
...and it still doesn't look right.
There we go. Of course, it doesn't preserve whitespace now...
Here's what I do on Linux:
First, kill anything that would be stressing the video card. I really don't know how to prioritize this, or even to get any sort of report on what's using my video card, how much RAM, how many pipelines, etc. For now, it should still be pretty easy. If Flash starts getting hardware accelerated, flash ads in your browser will lag you horribly.
Next, find any task that's using CPU and renice it down:
renice 40 -p `pidof a_huge_app`
And finally, play your movie at the highest priority:
sudo nice -n -20 mplayer -cache 102400 foo.mp4
There's probably a GUI somewhere for doing something similar. Point is, I've gotten CPU prioritization to work reasonably well -- I suppose YMMV? -- and I don't care much about IO prioritization when I've stuck a 100 meg buffer in front of it, especially as any OS or filesystem that can handle that much traffic in the first place should serve my process in a reasonable amount of time.
Then again, maybe that last point is mostly because I've got a RAID-0 system at home.
Disclaimer before I begin: When I say "core", I really mean "core and/or CPU". I mean this because multiple CPUs do still have cores, so calling a multi-CPU system "multicore" isn't that innaccurate, whereas calling a dual-core system "multi-CPU" is wrong. Also, "core" sounds better than "CPU".
Also not the same thing as pervasive message passing.
If you want to play the "me first" game, I mentioned Erlang before you entered this thread. Erlang takes the model you describe to an extreme -- a well-designed Erlang system could have hundreds, or thousands, of "processes", all of which communicate via message-passing alone. And note again, this is orthogonal to what you describe -- you may or may not be using message passing to do what you do, and an Erlang program may or may not be operating on the same data, or even somewhat "shared" data -- although Erlang would tend to encourage sharing less rather than more, when appropriate.
I should note also that I mentioned Erlang with the assumption that anyone interested would look it up (apparently you didn't), and with the full knowledge of what an Erlang-like system does. And I should also note that even in an Erlang program, it's possible your app doesn't scale as well as you think it does, and it's even possible you'll get some unexpected synchronous-ness, although I admit that is rare. But it's also hard to test for without actually running it on a multicore system.
And if they're not CPU-intensive, what's the point, honestly? If they're not CPU-intensive, they don't need to be threaded at all, just shove them all to an unused core; they probably won't fill it.
If you're not running anything CPU-intensive, hey, a single-core system still has a mostly-unused core. If you're running one thing that's CPU-intensive, shove them to that second core, which is in line with what I keep saying: Dual-core is fine and useful, but more than two isn't going to do much, most of the time.
Maybe "not CPU-intensive" isn't sinking in.
Right now, I'm on a laptop -- dual-core, 2ghz. I have 158 processes running. My system hasn't had more than 5% CPU used, and generally less than two. These processes include things like MySQL (just in case I want to do some Rails development, even though I'm using SQLite, but I haven't disabled MySQL yet), Kopete (for IM), ssh, Konqueror with, oh, eight tabs, Firefox with four tabs (all Google apps), a few virtual-machine related stuff (DHCP server, virtual switch, etc) in case I should want to fire up an XP machine, and so on.
Oh hey, and there's a Rails console sitting open... and four other Konsole windows I'd forgotten about on another desktop. Some of it might even be swapped out by now.
And it all still uses less than 5%. If we assume that's distributed fairly, and we take the 5% number (which is generous; it's more like 2%), it'd still be less than 10%.
Except a distinct lack of 2-N single-threaded apps needing to use a significant amount of CPU on a typical desktop. That was my point.
Go back to my original post, where I mention raytracing and make -jN. Povray isn't threaded itself; I'd have to run more than one of them, but I'm sure, given a big enough ani
Out of curiosity, is this still a limiting factor if top doesn't show CPU usage at 100%?
I mean, am I doing it wrong? I'm not the original poster, but look here:
david@worf:~$ dd if=/dev/urandom of=foo bs=1M count=100 100+0 records in 100+0 records out 104857600 bytes (105 MB) copied, 18.873 seconds, 5.6 MB/s david@worf:~$ scp foo localhost:~/foo.2 foo 100% 100MB 33.3MB/s 00:03 david@worf:~$(Whitespace truncated to fool lameness filter.)
Am I doing something wrong? I mean, this is a fast laptop, but still. Let me make the naive assumption that 64-bit is twice as fast as 32-bit, and 2 cores are twice as fast as 1. I got 33.3 MB/s on a dual-2ghz 64-bit processor, so we're pretending that's equivalent to an 8 ghz single-core 32-bit processor.
That means an 800 mhz, 32-bit machine should still be able to do 3.3 MB/s. By the same logic, at 80 mhz, you can do 300 KB/s, and at 40 mhz, you can still beat 150 KB/s, which is still faster than 124.6 KB/s.
Those are a lot of naive assumptions, both ways. In fact, it's ludicrously un-scientific, without being able to test against an actual server. (And besides, if I was needing to test bandwidth, I'd probably use netcat instead, on a random port, with some random data.) I'd also be curious to run both tests from other places.
But based on that, and on my experience with scp, I'd say that if you're getting less than about a meg per second on anything made in the last five years, scp isn't the limiting factor. That's a megabyte.
Would yours look like this religion?
I'm going to tread very lightly here, as I do not want to become a Rails fanboy.
That said, the two languages that were most useful for me at my current job are Ruby and Javascript. Ruby for Rails, and Javascript for HDi (before HD-DVD died). For the HD-DVD stuff, I had to use Visual Studio occasionally, but just look how useful my HDi skills are now... For the Rails stuff, I run Linux. Two of my co-workers run Windows, one runs OS X. The OS X guy uses TextMate, the Windows guys use Eclipse/Aptana (I think), and I haven't touched Visual Studio since the HDi stuff.
So it may not be easy (or even possible) to avoid ever seeing the MS tools, but "real businesses" use the right tool for the job -- or at least, what they think is the right tool for the job. It is possible to find an MS shop and never leave Visual Studio. It is also possible that you'll never touch Visual Studio.
I'm allowed to use whatever tools make me the most productive. Out of habit, that's vim and bash right now, but your mileage may vary -- a lot. What you already know has a big impact (I knew vim), and if you don't know anything (you're in school), you should be exposed to everything.
In particular, did you learn any Lisp/Scheme in school? What about Haskell? Or Erlang, or Smalltalk/Squeak? If not, you owe it to yourself to learn these now, even if you'll never use them at work. They will force you to think in different ways, and you'll come away with skills that apply to any language.
That's not big at all, for an OS manual!
Indeed, it does. The other way, though, as it should be.
That sounds great, as long as you provide the other side of it, too.
For instance, say I paid for 6 mbits. Boost me to 100 mbits if you like for the first few seconds, but after that, give me my 6 mbits.
I don't have a problem with Comcast "cheating" in this way. My problem is that you don't even get those 6 mbits you paid for ("unlimited" or not), you get "However much Comcast thinks you deserve" before they ban you for a year.
The "Captain Obvious" comment was in response to a statement which is always true. If an OS couldn't send additional tasks to another CPU, there would be no point to multicore at all, would there?
It's a bit like saying "A multitasking OS lets you run multiple tasks at once. You no longer have to stop one task to start another."
Good for you.
No, you've been saying "coarse multithreaded", which is a bit different than pervasive message-passing.
Never said there wasn't. How is "there is a gain" inconsistent with "it's completely unnecessary"?
I'm sorry, I'm really having difficulty parsing this one. Correct me if I read you wrong:
Do you mean background processes which are multithreaded and CPU intensive? That's what it looks like... But what does the system tray (or minimization) have to do with that?
If so, then I simply haven't seen many of these. Partly due to this "coarse multithreading" design that is so pervasive, partly due to things like global interpreter locks creeping in where people don't expect them, and mostly due to the fact that I simply don't have that many CPU-intensive background tasks I want to run in the first place, threaded or not.
And if they were written to scale properly, it would actually, in some circumstances, make things worse -- if a video encode can use 100% of 4 cores on a quad-core system, I have to prioritize it down, just as if it was using 100% of 1 core on a single-core system. Where multicore is providing the biggest perceptual gain right now is laziness -- I fire off one background video encode that can only saturate 1 core, maybe spill over a few minor IO threads and such and use 2% of the other core, and I still have most of a core free for anything interactive.
I realize the technological differences. But I think you see the philosophical implications here:
It may be possible to wire FTP servers together, by putting HTML pages on them, but I have no idea how current browsers would react. The Web is no more intrinsically connected -- in fact, there are a number of services which run over HTTP which aren't even particularly well connected internally, let alone to other servers.
So, on that level, the Web is less of a "network" than Gnutella is.
BitTorrent, while it is self-contained, is also every bit as much a "network" as the Web is. It's this way before even hitting the torrent file; I can Google for torrent sites, and some will link to others. At a lower level, there is actually a decentralized network built on top of BitTorrent, called DHT (Distributed HashTable), and even without that, one can add any tracers which are serving the same collection of files.
From a user interface perspective and from a censorship perspective, it's really no worse than Gnutella.
Really?
I don't even talk about Linux anymore, I talk about Ubuntu. (Now I can piss off both RMS and Linus!) Which distro does Dell pre-load and provide support for? Ubuntu. Why are we even having this discussion?
Because upgrading to 10.5 is neither free nor necessarily foolproof, or even an improvement. If you've been tracking Ubuntu, it's usually going to be a pretty gentle upgrade every six months, and it's as free as your Internet connection.
Then you just install Ubuntu. Yes, Kubuntu et al are out there, but it's very clear what the default is.
Also, what's the alternative? You want a Macbook, a Macbook Pro, a Macbook Air? In black or white? Glossy or matte?
You want Windows Vista... I guess that's Home Basic? Home Premium? Media Center? Ultimate? Or just XP Pro, because you hear Vista sucks? 64-bit?
Once again -- Ubuntu from Dell. Or the KDE-based thing that the EEE PC comes with. The choice is always there for you to find (apt-get install kubuntu-desktop), and it's only there if you look for it.
Anyone who Googles for advice is going to get a bunch of choices rammed down their throat anyway, no matter what they choose.
Or a shared NFS partition. Or a root image. Or a custom CD with packages burned to it.
This is a Solved Problem(TM).
Kopete is damned good. But it doesn't have a Windows port.
Amarok can do both of the things that you mention. It's not Foobar2000, but what is it missing that Foobar has?
Except that quite a few good games do work. I keep an XP partition anyway, but I'm hardly dependent on it.
Not true, actually. It may be that the only Linux software you've heard of runs on Windows, but that certainly doesn't imply that all good Linux software runs on Windows. Like Kopete, above.
Or, in other words, you win some, you lose some.
(Another random example: Ruby on Rails. You can develop on Windows if you like. It's not going to deploy easily (with Capistrano) to anything that's not vaguely Unix.)
Is that really all you've got?
And there's still KOffice.
Give it a year. There's already support for OpenGL on Windows via VirtualBox, and if you're running a VM on a Mac with hardware acceleration, keep in mind that Parallels is pretty much using Wine's Direct3D wrappers.
Welcome to Ubuntu.
Unless, of course, you're holding it to a higher standard of OUT-OF-THE-FUCKING-BOX-ness than your Mac, which didn't come with Photoshop, did it?
BitTorrent, as implemented today, is also relatively decentralized. No one torrent is, but BitTorrent itself is as decentralized as the Web -- anyone can throw up a tracker, or put a torrent on an existing tracker and seed.
Short answer: Yes, but not a lot.
Long answer: The advantage is that the single CPU-intensive thread can use an entire core, instead of having to share it with other things that might be running on your system. Except that these other tasks probably aren't using a significant portion of your CPU.
The other advantage, which I think I said in my original post, is that you don't have to worry about prioritization, at least not by yourself. No single CPU-intensive task is going to saturate your entire system. It'll fill one core, and you'll have a whole other core to play with. With a single-core system, you'd have to make sure that CPU-intensive task runs at a low priority if you want your system to be usable for anything else.
Of course, if you're insane, you can always run more than one of those CPU intensive tasks.
In my case, it was a no-brainer. I had a single-core system at 1.8 ghz, which I occasionally overclocked until I found out that it really was unstable at 2.4 ghz. Now I have a dual-2.4 ghz system.
If the computation was going to take a week, I can always drop the priority down and play games anyway, unless I don't have enough RAM. If I play games for a few hours a day, it might mean the week-long computation takes an extra day or so, and does that really matter so much?
Oh, and I'd transcode to h.264, anyway.
Thank you, Captain Obvious.
Which makes systems designed this way all the more interesting when they fall apart on a multicore system.
A side note: Amarok is a music player. It has absolutely no excuse to use any amount of CPU at all. That was a bug.
In other words, it helps when:
Remember that we're talking about Quake 3. If you split it up into nice, neat, "coarse" tasks, you might gain 5% or so over no mutithreading at all -- and maybe lose 5% on the single-core system. I think he did eventually manage to make it work well, but it was not easy.
This comes from the fact that even "coarse multithreading" isn't always easy. If you're using locks and semaphores, I'd argue that any sort of multithreading which must share data -- in Quake3, you're going to need to do culling, AI, physics, etc, all on the same model of the game world -- if you do that with locks and semaphores, it is probably one of the hardest problems in computer science. If you do it with message passing, it gets significantly easier, but it's still possible to have deadlocks, even in a pure message-passing system.
So, in most cases, you've got one core which is doing most of the game, and is saturated or close to it, and the other core is doing audio, compression, network, your standard antivirus, system tray apps, etc, and is at maybe 50%, if you're lucky. So dual-core does help, but three is pretty useless, unless you want to also be doing video encoding, raytracing, etc.
Are you sure? Played with Hyperthreading much?
Even if this is always true, it's also not necessarily relevant. Multicore systems are getting cheaper, so while it doesn't seem like a must-have to me as a consumer, I absolutely want to target them as a programmer. The classic example that I deal with at work now is, we use Ruby on Rails. The next version of the Ruby interpreter might offer as much as a 3x speedup, and even then, it's significantly slower than, oh, Java. But scalability is more important than performance -- this app runs on Amazon EC2, and if I need to, I can fire up another 20 or so servers, stick a load balancer in front of them, and we'll be able to utilize all of that.
So, sure, Rails is slower than some other solutions, but it's also very scalable, when done right.
(The real irony in that example is that Rails itself is not thread-safe, and that even if it were, Ruby has a global interpreter lock, so it could not utilize more than one core. This is resolved by running more than one Rails process on a single machine and putting a load balancer in front
There's no point. The phone lines can't carry cable signals.
Oh, I get it.
Your idealist Libertarian future involves another physical line for each possible competitor? Not only raising the barrier of entry, but wasting resources and trashing the environment, too?
It's disgusting even when you consider that it won't work.
I use Linux, and yes, I'm pretty sure. Note that I said "more than dual-core", not "more than a single-core".
Also, simply having more than one thread doesn't necessarily mean it scales to multiple cores. Look at the big scripting languages -- I'm not sure about PHP, but I can say that Perl is at least honest about using green threads, and while Ruby and Python use OS threads, they each have their own variant of a global interpreter lock, meaning that effectively, only one thread can be running a script at a time. I'm sure there are many systems designed like that -- naively "multithreaded", run fine on a single core, but either won't fully utilize a second core, or will actually start crashing.
Regarding your example, let's see... Spreadsheets? Really? Throw it on a single-core, 3 ghz, it'll be fast enough. If not, it's doing something that spreadsheets were never designed to do. Again, dual-core might help, but I really don't see more than that being useful -- not because Excel is necessarily not threaded, but because it couldn't find anything reasonable to do with that extra power.
Or a game -- fine, audio in one thread. Audio that uses maybe 0.5% of the CPU. Networking -- what, 1%? And so on... Games are also the least likely to use languages that scale naturally (like Erlang), because for a long time, they've been programmed in languages like C and C++, trying to squeeze every last ounce of performance out of a single core. The story goes that when John Carmack got a dual-core system (or was it dual-processor?), he tried to make Quake3 multithreaded. In his first attempt, he made it slower than it was single-threaded.
Well, let's see...
The video itself doesn't necessarily use all of a single core. But even if it does, you still have one more.
There is multithreaded h.264, but it requires that the video was encoded that way, and there's a slight loss in quality (or bit efficiency). This is because, if I understand it, the way multithreaded h.264 works is, it slices the video up, physically. Imagine a vertical bar down your 1080p display -- everything on the left is one thread, everything on the right is the other.
I think it's nice that this kind of thing is supported, in case it's ever useful -- particularly in much higher-resolution video -- but right now, I don't see it being particularly helpful. And again, a lot of the gain is in not having to set thread priority -- if I'm encoding, I generally don't care how long it will take, so I could just set that to the lowest possible priority, and watch all the video I want, even on a single core.
Now, I know how I could fill a quad-core, but none of the uses I can think of really have much everyday utility to me, at least until games start using them properly.
I think you got it with that link, but just in case...
The green threads are a necessity, as most native OS threads won't handle the sheer number of Erlang "processes" that might be running.
But you can specify an arbitrary number of "real" threads to load-balance the green threads against.
Erlang also has ludicrously easy (and insecure) "native" RPC, so it scales easily to a cluster of (trusted) computers. It also has reasonably easy socket programming, but it's generally not as good as the native RPC, when it's an option.
Sounds exactly like the old Napster. The RIAA struck it down, and it has returned as BitTorrent, more powerful than the RIAA could possibly imagine.
Last I checked, they not only had long latencies, they also had horrifically slow upload speeds and possibly some throttling/metering of their own. But I live in an area with decent options, so I don't really know.
In any case, you've just illustrated two important points: