- Microsoft Vista SP1 is out finally.
- IPhone users are heavy Internet users. Duh. It’s a luxury.
- Steve Jobs hates flash.
- Intel working on 8-core chip.
- Another Congressman slams tech companies. Why? He is looking for cash.
- DVB-H is finalized?
- 700 Mhz sale is over, finally.
Right click here and select ‘Save Link As…’ to download the mp3 file.
The problems with dividing an application among two or more processors (or even 8) has been studied, and solutions proposed, since 1990 or so (I was in grad school at the time).
Two cores is relatively simple; we have that now.
Dividing a task among N cores doesn’t speed things up by a factor of N, because the processors also have to communicate with each other, and with 8 cores, there are a lot of paths for data to take.
What’s needed is a general algorithm that can divide a computing task among an arbitrary number of cores without having to recompile the OS or application.
However, a lot of tasks just can’t be arbitrarily divided into chunks, as the output of one core needs to be sent to one or more cores.
Excuse me while I stop thinking about this problem, as my head spins again from thoughts of the complexity…
We already have the ability to code for multiple cores. It is called multi-threading. Any application that takes use of multiple threads, which is most except for games, makes use of multiple cores. Furthermore, running multiple applications makes use of multiple cores. However, coding for multiple threads is orders of magnitude more complicated to write and debug than coding for single threaded. On top of that, as #1 mentioned, in a single application, you do not get a factor N performance because of context switching between the threads.
Frankly, multi-threading is beyond 80% or more of the developers out there. The only way that applications will make better of use of multiple cores if it happens at machine or assembly level so that developers do not have to think about it.
I used to think that browsing the web on a mobile phone is useless. I’ve used my Panasonic maybe 5 times within the last 3 years, it’s a pain. On the recent trip to EU I noticed my wife continuously being on the net with her iPhone (she is running couple of websites with bbs), so I finally grabbed the phone and tried it. I have to say it works as advertised, I can imagine people using it daily and even as their only browser (damn Flash).
User experience equals a 15″ screen, but it’s difficult to compare since the zoom in/out and finger riding the page works so well. I had no problem with thumb typing, it would probably work with big toe typing too.
She didn’t have the phone part activated for the whole trip, but here in China the GPRS speed is not too bad. I can imagine people using GPRS to browse the web anywhere and willing to pay for it, especially if you are stuck on San Mateo Bridge for couple of hours or stuck in slow moving traffic in general.
We already have the ability to code for multiple cores. It is called multi-threading. Any application that takes use of multiple threads, which is most except for games, makes use of multiple cores.
It’s less complicated in some ways, and more complicated in other ways, than you imply.
Multiple threads != multiple cores. Not necessarily, anyway. Windows, for one, doesn’t seem too smart about this. You have to futz with the affinity, which microsoft suggests that you avoid. The best you can do is “suggest” the ideal affinity and hope no other brain-dead application (like, for instance, some of that unneeded crap that MS loves to constantly run in the background) screws you over.
For real multi-processor programming, you need constructs within the language over and above threading. Loop unrolling is just one example: properly done, there should be two types of loops, explicitly chosen by the programmer; one for loops in which each iteration is independent of the others, another for when each iteration may depend on previous results. The former can be unrolled into multiple processors for parallel execution; the latter cannot. The compiler has no (reliable) way to determine this on its own. I’m not aware of any production language that can do this at this time, although I’m sure some academic or proprietary languages can (LINDA, etc.)
Furthermore, running multiple applications makes use of multiple cores.
Again, theoretically possible but not implemented very well in Windows. Futz with affinity, but I’ve tried and it doesn’t seem to really make any difference, and as with thread affinity, you risk running afoul of the poorly implemented windows routines that run all of the time. (Look at the processes in your tasklist.)
However, coding for multiple threads is orders of magnitude more complicated to write and debug than coding for single threaded.
The good news is, that isn’t true. It just requires a different mindset and learning some straightforward rules on syncronization using semaphores, shared memory, etc. It’s beyond that ability of most of the kids who think javascript is a language, but not that big a deal for real programmers.
“700 Mhz sale is over”
Awsome! when do we all get our cut of the umpteen billion dollars “our” spectrum was sold for?
John,
All of the AT&T plans for the iPhone include unlimited data. I have a iPhone and to be honest the internet speed sucks unless you are on a WiFi signal, which for me is at home so it makes it pretty useless. But as far as phone bills, mine is always the same, month in month out no matter how much data transfer I use.
> Multiple threads != multiple cores.
I never said that it was. However, by coding for multiple threads you *are* coding for multiple processors. With affinity, you are simply tweaking the scheduler. Sure, Microsoft could improve their context scheduler algorithms but that will not make coding for multiple threads any easier. That will simple lower the cost slightly for context switching.
RE: Multiple applications and affinity
What exactly are you attempting to achieve? Are you attempt to push one application to a specific processor?
RE: Multi threading coding.
Sorry but I disagree. Sure the language constructs are simple enough to learn but the mindset you are discussing is way beyond most developers. The core issue is that multi-threading does not lend itself to cowboy coding in any shape or form. You need to be disciplined in the manner you code along with knowing the language constructs and having that mindset. That you cannot cowboy-code puts it out of the reach of most developers (thankfully). Many languages do not have constructs for multi-threading and some of the ones that do probably should not (VB.NET comes to mind).
Yeah, it would be great to have a smallish antenna in a mobile phone that could pick up regular digital broadcasting. The technical problems seem to center around multipath reception disturbances. With movement of the receiver, doppler effect problems also come into play. To counteract these problems, up to 3/4 of the broadcasted information to these little devices has to be error correction information.
It’s a tricky business. The 8-VSB standard that is used in regular digital video broadcasting allows the transmission of programs at a tenth the power of NTSC broadcasts, but the high-power requirements for 8-VSB reception make for great difficulties in small low powered receiving devices.
John,
Come out of your cave and enjoy the iPhone unlimited data plan. Don’t you cover this stuff?
I never said that it was.
Sorry.
I guess we basically agree.
I personally LOVE threads. I used to do a lot of pseudo-threading using state machines under DOS. You have to implement all the syncronization functionality yourself, but it was a lot of fun, and kind of amusing to demonstrate how powerful computers really could be (in the DOS days, that is) when you could write software that didn’t spend 99.9% of its time waiting for user input.
Nobody is reading this thread any more, are they?
>>Nobody is reading this thread any more, are they?
I think I was, then I woke up.