Slashdot Mirror
Is Parallelism the New New Thing?
astwon sends us to a blog post by parallel computing pioneer Bill McColl speculating that, with the cooling of Web 2.0, parallelism may be a hot new area for entrepreneurs and investors. (Take with requisite salt grains as he is the founder of a Silicon Valley company in this area.) McColl suggests a few other upcoming "new things," such as Saas as an appliance and massive memory systems. Worth a read.
When I was in graduate school in the mid '90's I thought Parallelism would be the next big thing. Needless to say I was a bit early on that prediction. Finally maybe those graduate classes and grant work will pay off. :-)
Think Deeply.
32G chips and put them in 4 slots on my 64 Bit PC before talking about 'massive memory'
The Kruger Dunning explains most post on
Someone in another recent thread mention the TRIPS architecture. It's quite interesting reading.
A-Bomb
This seems far, far too low. Admittedly I work in a place that does "parallel programming," but it still seems awfully low.
This post climbed Mt. Washington.
Parallelism is just a means to a business feature - performance. If clients want it, then there will be capital for it. If they don't, then it won't matter to them.
This is my sig.
Paul ?
Paul Otellini ?
I didn't know you posted on slashdot !
So what's up man ? Can I buy you a beer ?
the guy has a "startup in stealth mode" called parallel computing. Of course he wants to generate buzz.
Decade after decade, people keep trying to sell silver bullets for parallel computing: the perfect language, the perfect network, the perfect os, etc. Nothing ever wins big. Instead, there is a diversity of solutions for a diversity of problems, and progress is slow but steady.
Like most topics in computer science, it's a "New Old Thing".
A guy who's made it his life's work to study Parallel Computing has come forth to say, he thinks Parallelism is the next big thing?
Shock! And Awe!
For having been in the computer industry for too long, I reckon the "next hot thing" usually means the "latest fad" that many of the entrepreneurs involved in hope will turn into the "next get-rich-quick scheme".
Because really, anybody believes Web-Two-Oh was anything but the regular web's natural evolution with a fancy name tacked on?
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
Now that we are seeing more and more in the way of multi-core CPUs and multi-CPU computers I can definitely see parallelism become more important, for task that can be handled this way. You have to remember that in certain cases trying to parallise a task can end up being less efficient, so what you parallelise will depend on the task in hand. Things like games, media application and scientific applications are usually likely candidates since they are either doing lots of different things at once or have tasks that can be split up into smaller units that don't depend on the outcome of the other. Server applications can to a certain extent, depending whether they are trying to the same resources or not (ftp server, accessing this disk, vs a time server which does not file I/O).
One thing that should also be noted, is that in certain cases you will need to accept increased memory usage, since you want to avoid tasks locking on resources that they don't really need to synchronise until the end of the work unit. In this case it may be cheaper to duplicate resources, do the work and then resynchronise at the end. Like everything it depends on the size and duration of the work unit.
Even if your application is not doing enough to warrant running its tasks in parallel, the operating system could benefit, so that applications don't suffer on sharing resources that don't need to be shared.
Jumpstart the tartan drive.
Tied in with parallelism is the issue of doing something useful with the billions of transistors in a modern computer. During any microsecond, how many of them are doing useful work as opposed to just generating heat?
Mea navis aericumbens anguillis abundat
Oh yes, here it is.
And the conclusion?
It's been around for years numbnuts, in commercial and server applications, middle tiers, databases and a million and one other things worked on by serious software developers (i.e. not web programming dweebs).
Parallelism has been around for ages and has been used commercially for a couple of decades. Get over it.
Not parallelism... Why do MBA idiots have to fill everything with their crap? Now they'll start creating buzzwords, reading stupid web logs (called "blogs"), filling magazines with acronyms...
Coming soon: professional object-oriented XML-based AJAX-powered scalable five-nines high-availability multi-tier enterprise turnkey business solutions that convert visitors into customers, optimize cash flows, discover business logic and opportunities, and create synergy between their stupidity and their bank accounts - parallelized.
I was about to say 13256278887989457651018865901401704640, but it appears this number is private property.
This sure looks like a growth area for qualified developers. An audience poll at the Gartner Data Center conference in Las Vegas in November found that just 17 percent of attendees felt their developers are prepared for coding multi-core applications, compared to 64 percent who say they will need to train or hire developers for parallel processing. "We believe a minority of developers have the skills to write parallel code," said Gartner analyst Carl Claunch. I take the Gartner stuff with a grain of salt, but the audience poll was interesting.
McColl's blog is pretty interesting. He only recently started writing regularly again. High Scalability is another worthwhile resource in this area.
...about the new new thing? That's old. We want the new new new thing!
So all-of-a-sudden people have discovered parallelism? Gee, one of the really interesting things about Ada in the late 80s was its use on multiprocessor systems such as those produced by Sequent and Encore. There was a lot of work on the language itself (that went into Ada95) and on compiler technologies to support 'safe parallelism'. "Safe" here means 'correct implementation' against the language standard, considering things like cache consistency as parts of programs get implemented in different CPUs, each with its own cache.
Here are a couple of lessons learned from that Ada experience:
1. Sometimes you want synchronization, and sometimes you want avoidance. Ada83 Tasking/Rendezvous provided synchronization, but was hard to use for avoidance. Ada95 added protected objects to handle avoidance.
2. In Ada83, aliasing by default was forbidden, which made it a lot easier for the compiler to reason about things like cache consistency. Ada95 added more pragmas, etc, to provide additional control on aliasing and atomic operations.
3. A lot of the early experience with concurrency and parallelism in Ada learned (usually the hard way) that there's a 'sweet spot' in the number of concurrent actions. Too many, and the machine bogs down in scheduling and synchronization. Too few, and you don't keep all of the processors busy. One of the interesting things that Karl Nyberg worked on in his Sun T1000 contest review was the tuning necessary to keep as many cores as possible running. (http://www.grebyn.com/t1000/ ) (Disclosure: I don't work for Grebyn, but I do have an account on grebyn.com as a legacy of the old days when they were in the ISP business in the '80s, and Karl is an old friend of very long standing....)
All this reminds me of a story from Tracy Kidder's Soul of a New Machine http://en.wikipedia.org/wiki/The_Soul_of_a_New_Machine. There was an article in the trade press pointing to an IBM minicomputer, with the title "IBM legitimizes minicomputers". Data General proposed (or ran, I forget which) an ad that built on that article, saying "The bastards say, 'welcome' ".
dave
Sorry guys, web 2.0 was never cool and never will be.
mcgrew's razor: Never attribute to stupidity that which can be explained by greedy self-interest
Will "Parallelism" be the next new thing? Well... no. That's like asking if "for loops" are going to be the next big thing. It's a tool, to be used when appropriate and not used when appropriate. It's going to be very hard to convert "Parallelism" into a magic VC pixie dust.
/. discussion).
I say this as someone who has recently been tuning his career, experience, and personal projects towards learning more about parallel programming in practice, and I still don't see this as a "next big thing". It's just another in a long list of skillsets that is going to be gradually more useful over the next few years. I still think it's a good move to learn about it (and I'm putting my effort where my mouth is), but I don't see it sustaining any sort of bubble.
One thing I did learn from the last discussion is that a lot of people are very far behind on parallelism, though; if you think locks and pthreads are the state of the art, you've got some catching up to do. There's been a lot of practical progress in the past ten years that doesn't seem to have made it into the popular consciousness of Slashdot programmers. (And I emphasize the word practical; it's not just academic wanking anymore, or libraries optimized for such.) I suggest anyone interested in the topic check out Erlang and Software Transactional Memory (in that order). Whether these technologies will "win" I don't know, but Erlang in particular, while it may in some sense not contain a single idea that can't be traced to the 1960s, is unique in being a complete runtime and library based on ideas-that-will-be-new-to-you (most likely, based on the previous
Analysis tools, code-that-analyses code accurately, will finally need to get off the ground if we're going to get out of this gap. Otherwise, we're just going to see hundreds to thousands of hardware-supported, virtualized, inefficient pseudo-threads and tons of message passing analogies.
Shared memory contention is a hardware-solved problem at this level of integration. Shared memory code never lives up to its possible speed in most programming, except for the OS.
I'm entering grad school for this. There's more funding than there are students! Let's get on it!
Nietzsche is dead - God
So I started writing without reading TFA. Then I read TFA to be sure that I was not in fact missing something. I'm not, and you're not either... The assertions of the article are absurd - someone must have felt that they needed to put something on the web for google to index.
While not related to parallelism I especially like "SaaS as an Appliance. One area within SaaS that is growing quickly is the opportunity to deliver a SaaS product as an appliance."
So you mean to tell me that the next big thing is installing software on a server, and installing that server in my datacenter and supporting it?! New!? HA HA HA. So actually what you are saying is that SaaS is too limiting, unreliable (from a connectivity perspective) or not secure enough for client needs and that we have to do it the Old way.
As far as the last item in the Blog goes I'm not sure where all of this crazy excitement over parallelism is coming from. There have been several posts on slashdot over the last few weeks regarding it. Massive parallelism has been available for decades for very special types of scientific problems that merit the additional complexity of coding them up. Parallelism has also been available in the form of threads.
The real conundrum is that not many problems on the desktop are in fact, parallel and if they are then one would utilize threads, and if really needing to be sure the OS is behaving itself, processor affinity would be used as well. This would allow, given the proper task, one to fully utilize every cycle of the available cores. The real desktop problem is how can most efficiently allocate processes across multiple cores and physical CPU's.
The tools to do this are available today, here and now! Just get your latest copy of Xcode, VS Studio, or GCC! Unless someone reinvents the way we code I'm not sure that anything is going to happen here.
Former venture capitalist Jeff Nolan has been agonizing this week over "what's next?" and "where the venture capitalists will put all that money?"
It really sounds like he is shilling.
But seriously, first it was DP and COBOL.
Then expert systems.
Then relational databases.
The object orientation.
Then webification.
Then XMLification.
Then web 2.0.
And probably a few I missed.
I think this is just another fad.
putting the 'B' in LGBTQ+
I'm not trolling. Sun, Intel, Nvidia, and ATI/AMD (for obvious reasons) have been investing in this area for years. I think that constitues Silicon Valley investments (except for those crazy Canadians at ATI).
Now that multi-core computers have been out I keep hearing buzz around the idea of parallel computing, as if it is something new. We've had threads, processes, multi-CPU machines, grid computing, etc etc for a long time now. Parallelism has been in use on single processor machines for a long time. Multi-core machines might make it more attractive to thread certain applications that were traditionally single-threaded, but that's the only major development I can see. The biggest problem in parallel computing is the complexity it adds, so hopefully developments will be made in that area, but it's an area that's been researched for a long time now.
You think that nobody has a real interest in parallel computing? Intel's put their money on it already - they've allotted $20 million between UC Berkeley and University of Illinois to research parallel computing, both in hardware and software.
I am a EECS student at Cal right now and I have heard talks by the UC Berkeley PARLab professors (Krste Asanovic and David Patterson, the man who brought us RAID and RISC), and all of them say that the computing industry is going to radically change unless we figure out how to efficiently use parallelism. This is the first time in history that software performance is beginning to lag behind how fast we can make our hardware. The failure of the frequency scaling to continue to improve system performance has been shown in the failure of the NetBurst microarchitecture - remember the Prescott? And the failure of the Tejas and Jayhawk? Building faster chips is over, it's a mechanical engineering issue - we can make chips put out more heat per area than the surface of the sun. Quoting professor Hennessey from Stanford:
"...when we start talking about parallelism and ease of use of truly parallel computers, we're talking about a problem that's as hard as any that computer science has faced. ... I
would be panicked if I were in industry. ... you've got a very difficult situation."
To whoever is saying that parallelism is just a fad, you're really missing a lot of what's going on in the computing world. We've already switched to dual- and quad-core CPU's, and it doesn't look like it's going to stop any time soon.
We know three kinds of parallelism that work: clusters, shared memory multiprocessors, and graphics processors. Many other ideas have been tried, from hypercubes to SIMD machines, but none have been big successes. The most exotic parallel machine ever to reach volume production is the Cell, and that's not looking like a big win.
Graphics processors are the biggest recent success. They're still very difficult to program. We need new languages. C and C++ have the built-in assumption that all pointers point to the same memory space, and don't address concurrency at the language level at all. That's not going to work. The "dynamic languages" (Javascript, Python, etc.) have too much overhead. Special purpose graphics languages (Renderman, etc.) address the high concurrency issue, but only for a limited class of problems. None of the traditional parallel languages (Occam, etc.) have enough of a user base to make them compelling. Interestingly, what does look promising is compiling Matlab to GPU code; the big matrix operations of Matlab translate well to GPU-type machines, and number-crunching engineers like and use Matlab.
If your problem isn't a good match to either Matlab or RenderMan, though, it's all uphill right now.
Being able to simply say "the order in which these tasks are made doesn't matter" lets you run a lot of tasks in parallel right there.
Mucking around with language design and implementation highlights some of the deep problems that the "parallize-everything" crowd often don't know about.
In your example, the loop can only be efficently parallized if it doesn't have any side-effects. If any variables are written to out of scope of the loop, then they are exposed to race conditions in both the read and write direction. It's still possible to parallize the code if the machine code doesn't take advantage of the memory model of your architecture, and no other thread is modifying those variables, and it doesn't matter in which order the variables are modified, and modifications are atomic. As an implementation detail, memory reads and write will be signficiantly slower, and sychronization of atomic operations is also not without cost. So much in fact, that you'd probably be better off just running the loop on a single thread. Your code will be more predictable regardless.
At the moment, it seems that effective parallization requires some planning and effort on behalf of the programmer. The bugs can be extraordinarily subtle, impossible to debug and difficult to reason about. Expect single-threaded programming models to be around for a long time.
Like all pain, suffering is a signal that something isn't right
You see, the majority of the programmers out there don't know much about parallelism. They don't understand what synchronization, mutexes or semaphores are. And the thing is that these concepts are quite complex. They require a much steeper learning curve than hacking a "Web 2.0" application together with PHP, Javascript and maybe MySQL. So if now everybody will start writing multithreaded or otherwise parallel programs, that's going to result in an endless chain of race conditions, mysterious crashes and so on. Rembember, race conditions already killed people.
Needless to say I was a bit early on that prediction.
The reason is that all academic researchers jumped on the multithreading bandwagon as the basis for parallel computing. Unfortunately for them, they could never get it to work. They've been at it for over twenty years and they still can't make it work. Twenty years is an eternity in this business. You would think that after all this time, it would have occurred to at least one of those smart scientists that maybe, just maybe, multithreading is not the answer to parallel computing. Nope: they're still trying to fit that square peg into the round hole.
Both AMD and Intel have invested heavily into the multithreading model. Big mistake. Multiple billion dollar mistake. To find out why threads are not part of the future of parallel computing read Nightmare on Core Street. It's time for the computer industry to wake up and realize that the analytical engine is long gone. This is the 21st century. It's time to move on and change to a new model of computing.
Nobody knows how to efficiently program such pervasively parallel systems. Yes, it would be the next big thing but it only wont.
"Parallelism has been around for ages and has been used commercially for a couple of decades." - by Nursie (632944) on Friday March 28, @10:50AM (#22893630) Homepage True, & NOT JUST IN COMMERCIALWARE (freeware/shareware too, for a LONG time):
APK Registry Cleaning Engine 2002++ SR-7:
http://www1.techpowerup.com/downloads/389/APK_Registry_Cleaning_Engine_2002++_SR-7_.html
or
http://www.techpowerup.com/downloads/389/APK_Registry_Cleaning_Engine_2002++_SR-7_.html
(Either link SHOULD work fine to see it)
Above ALL else:
SCREENSHOT:
http://www1.techpowerup.com/downloads/screenshots/389.jpg
or
http://www.techpowerup.com/downloads/screenshots/389.jpg
(Again - either link URL should work to check this out as an example of what you state, that multithreaded (& thus, SMP ready code) has been around for decades, since that app began its life in 1997 in fact, in freeware no less... so, it's NOT just present in commercialware apps either, but also shareware/freeware also).
Hey - I am just a SINGLE example of a guy that's been doing "multithreaded apps", since 1995 or so, online: & there are TONS of others that do also!
(In fact, anyone can examine their windows machine for the presence of multithreaded code, & see that MOST of what you use today IS multithreaded in fact - I run 30 processes here, & 28 of those ARE MULTITHREADED & thus, SMP-ready code!)
Multithreaded code is taken advantage of by the kernel portion memmgt subsystems of today's MODERN OS for better MULTITASKING (getting more done, by more cores/arms to do work with, so overall MORE GETS DONE (think of Gantt charts).
(Microsoft isn't alone here either - BSD variants & Linux variants too also do this (which Linux's original single kernel thread/round-robin usermode/Ring 3/RPL 3 "threads" were only sent thru the SINGLE kernel mode/RPL 0/Ring 0 one)...
In fact? That fact held Linux back from the "Enterprise ready class OS" acceptance for a LONG time, until they built a REAL SMP ready setup (iirc, around kernel 2.2 build or so on Linux kernels (but, I could be off here on the specifics))).
APK
P.S.=> Granted, what I use is "coarse grained" multithreaded design, which amounts to doing diff. tasks that process/touch DIFF. DATA, as they operate (rather than "fine-grained multitheading", which is taking a single data set & running portions of its processing on diff. threads BUT, on the SAME DATA (harder to do & NOT everything lends itself to it)).
E.G.=>
A=B+C
B=A-C
C=B+A
You cannot put this type of thing into threaded design, & expect gains out of it... simply because B has to WAIT on the completion of A, first... no point in placing A or B onto diff. threads, in other words... apk
Electricity, Automobiles, and the telephone!
Seriously, didn't we decide that parallel programming was the next big thing when Sutter wrote a big article in Dr. Dobbs a couple of years ago?
Welcome to the party pal, we've been here a while already!
"We need a fourth law of Robotics: Stop Fingering My Wife"
TFA is mainly about SaaS - Software as a Service (yes, I had to look it up). GMail, Google Calendar etc. in other words.
Honestly I think that parallelism and SaaS are pretty much on the opposite sides of the spectrum. Your typical SaaS application requires no parallelism whatsoever since they are typically low-impact programs. The only real improvement over ordinary software is that you don't have to install it, don't have to maintain it and that you can access it anytime from anywhere.
A typical SaaS provider has a few dozen to a few thousand servers running a few hundred to a few million instances of his software. Since typically a single server will run many instances of the software, parallelization will "just happen" for free.
A typical SaaS client runs in a web browser. Since a web browser is probably about the least efficient application GUI ever made (it runs in Javascript over XML over HTTP and uses HTML and DOM to "emulate" a drawing library), parallelization is not your problem there either.
SaaS can be great and so can parallelization. But they're not related.
http://vinay.howtolivewiki.com/blog/hexayurt/supercomputer-applications-for-the-developing-world-375
We've seen unambiguously that **GIGANTIC** data sets have their own value. Google's optimization of their algorithms clearly uses enormous amounts of observed user behavior. Translation efforts with terabyte source cannons. Image integration algorithms like that thing that Microsoft were demonstrating recently... gigantic data sets have power because statistics draw relationships out of the real world, rather than having programmers guessing about what the relationships are.
I strongly suspect that 20 years from now, there are going to be three kinds of application programming:
1> Interface programming
2> Desktop programming (in the sense of programming things which operate on *your personal objects* - these things are like *pens and paper* and you have your own.)
3> Infrastructure programming - supercomputer cluster programming (Amazon and Google are *supercomputer* *applications* *companies*) - which will provide yer basic services.
Real applications - change the world applications - need parallel supercomputer programming.
Hexayurt - open source refugee shelter,
The HPC Cluster people have thought about this stuff for a while. One approach that I have thought about is described in the article:Cluster Programming: You Can't Always Get What You Want There are two follow-on articles as well Cluster Programming: The Ignorance is Bliss Approach" and Cluster Programming: Explicit Implications of Cluster Computing.
Of course if you really want to know how I feel about this: How The GPL Can Save Your Ass
enjoy
HPC for Primates. Read Cluster Monkey
We *already* live in a parallel computing environment. Almost every computer has a large number of processes and threads running simultaneously. This *is* parallelism.
Granted, yes, certain products could benefit by extreme threading, i.e. like PostgreSQL breaking the hierarchy of query steps into separate threads and running them in parallel, like doing a more exhaustive search for the query planner using multiple threads, and stuff like that, but there is always going to be the competition between performance for a single logical process vs the performance for the system as a whole.
Maybe when/if we get more cores than processes it makes sense, but right now we use all the cores we have. As long as your load average is non-zero, you may be able to benefit from more cores.
Oh yeah, no "commercial only" thing was meant there, sorry to imply it. Apache web server would be an example of something that's been using these feature for some time too.
"You cannot put this type of thing into threaded design, & expect gains out of it... simply because B has to WAIT on the completion of A, first... no point in placing A or B onto diff. threads"
Oh sure, but where you have multiple threads doing seperate, non-codependant tasks you can parallelise really quite well.
Anyway, yes, my main point is my continued exasperation at folks who say "it's the next big thing" or "it'll never take off". It's here and has been for years!
I'm pretty sure that OS X will distribute threads across however many cores it has to work with. What about MSFT XP, Vista or the Linuxes ? If a program creates 2 threads and the machine has 2 cores, will the OS assign threads accordingly ? Probably depends on current workload, but if the 2 threads are on separate cores then they're running in parallel, right ?
Parallelism was the New New Thing when the Inmos Transputer rolled out in 1984 - a CPU explicitly designed to allow multiple CPUs to co-operate, and with a hardware scheduler to provide on-chip parallelism. Then we had the GAPP (Generalised Arithmetic parallel processor), the Connection Machine, and lots of other weird architectures whose names I cannot recall. I designed one myself in the late eighties, and we took it to breadboard stage (essentially Hyperthreading write very large).
Forgive me for not getting too excited by this new dawn. I have seen too many false dawns. Yes, parallelism is getting more and more prevalent, but expect more incremental steps, not an explosion.
Consciousness is an illusion caused by an excess of self consciousness.
I am still trying to figure out what people are talking about with web 2.0?
With compuserver (1969), BBS's (1970's), UseNet, E-mail & The Source (1979), The Well & Q-link (1985) we have online communities this whole time. With IRC we have been IM Chatting since 1988.
And almost all of this existed over the IP based Internet starting around 1983 and starting in 1993 it became http/browser based. I have been using all of these early after their inception.
So what is new about Web 2.0? I can't see anything new at all, not even a little. Am I missing something.
Same with Parallelism.
I was a member of the Parallel Computing Connection PPC a club run by Mitchell Loebel in Silicon Valley going back to 1989 that later renamed itself into the Tech Startup Connection http://www.techstartupconnection.org/ . From that club things like the NUMA Architecture arose.
Before that Thinking Machines Corporation by Danny Hillis 1982 with the "Connection Machine" and nCUBE.
Earlier was Control Data Corporation (CDC) and Cray which although technically not parallel processors used parallel Arithmetic circuits.
But even the Code breaking machines in WW2 used massive parallelism.
Richard Feynman's work on the Manhattan project, in which in one of his books (I think is was "Surely You're Joking, Mr. Feynman!") he describes a human assisted parallel computer with banks of Primitive IBM computers with humans moving stacks of punch cards between them to plow through the math needed to build the Bomb.
Point being, that in all of the excitement of Internet for the average Joe we forgot about most of these technologies and are now returning to it.
So there isn't anything new here, just a rediscovery.
How to use so many cpu's under Panic in Multicore Land March 11, 2008
http://developers.slashdot.org/comments.pl?sid=483070&threshold=0&commentsort=0&mode=thread&cid=22719658
Ask Chuck Moore About 25X, Forth And So On , Aug 28, 2001
http://slashdot.org/developers/01/08/19/1712249.shtml
I am always doing that which I can not do, in order that I may learn how to do it. - Pablo Picasso
"Oh sure, but where you have multiple threads doing seperate, non-codependant tasks you can parallelise really quite well." - by Nursie (632944) on Friday March 28, @12:30PM (#22894808) Homepage Which is EXACTLY what I did in the example app I wrote & posted... Hence, why I posted the varying design methods possibles on multithreaded code (which due to today's modern OS' process scheduler kernel subsystems componentry, IS thus, "implicitly SMP ready").
It's much simpler to do, & lends itself to MORE SMP READY SOLUTIONS than does "finegrained" multithreaded (working on SAME DATA, via multiple threads) design (which again, per my last posts' example via mathematics, does NOT always lend itself to gains of ANY kind really).
Even "coarse multithreading" (doing diff. data on DIFF. THREADS) adds "gains"!
(Especially if SMP processor/core #1 (0 actually iirc regarding arrays) is saturated to 100% or nearing it. This is when multiple thread design can help (& no "SetProcessorAffinity" EXPLICIT multithreaded designs required either (means more code for processor detection, & also scheduling manually etc. et al))).
I designed MORE for creating a "Good Multitasking Citizen of the System" via threads, AND CPU-priority control as well... see screenshot of its interface for that latter note.
I was out to make it as GOOD a multitasker as possible via the design methods I used (not so much for sheer SPEED, as it was designed more for unobtrusive background operation)...
----
Also, "APK Registry Cleaning Engine 2002++ SR-7" TRULY IS, the safest registry cleaner there is, bar none, as well!
So, how can I say that?
Well, because I didn't make the 'foolish mistake' others have that design them... & that mistake?
EXPOSING TypeLibs & CLSIDS (class identifiers) as valid candidates for deletion by END USERS, that unfortunately, most times DO NOT UNDERSTAND THEM or how they work
(I.E.-> CLSIDS & TypeLibs are tools in the registry PLUS on disk (on the latter) which OLEServer DLLs use - blow the WRONG ONE OF THOSE? Don't wonder WHY stuff in your OS, or apps, stops working!)
(Dumb move - putting lit matches into the hands of children, living in a tinderbox, exposing those for candidates for deletion from the registry that is... I filter vs. that, & no problems come up in the way of OLEServers/ActiveX controls etc. et al - & it works ALL THE WAY ACROSS ALL 32-bit Windows (9x/NT/2000/XP/Server 2003), flawlessly AND SAFELY!)
Actually, I find my app has larger benefits than speed up help - It's MORE USEFUL imo @ least, as a forensics tool... what you use on your systems can easily "paint a picture" about you... & this app can either help secure you THAT way, or aid forensics investigators (it has me professionally in THAT capacity, more than once, this is CERTAIN).
APK
P.S.=> "Anyway, yes, my main point is my continued exasperation at folks who say "it's the next big thing" or "it'll never take off". It's here and has been for years!" - by Nursie (632944) on Friday March 28, @12:30PM (#22894808) Homepage And, you're correct! Anyone can verify it, using tools like Windows NT-based OS' own taskmgr.exe (or, Microsoft's/SysInternals' ProcessExplorer!). MOST OF WHAT MOST FOLKS RUN, both in OS' AND APPS, is multithreaded & has been for more than a decade now.
----
"Oh yeah, no "commercial only" thing was meant there, sorry to imply it" - " - by Nursie (632944) on Friday March 28, @12:30PM (#22894808) Homepage Oh, I actually didn't THINK you were implying it was for "commercialware only"... it's just that I wanted to clarify the fact that multithreaded design (& thus, implicitly operating SMP ready/parallelism ready code) DOES EXIST & for a LONG while now, in freeware/shareware as well as commercialwares is all.
(My app merely concretely exemplifies it, via my single example above only (there are TONS more too)).
Don't want others misled is all... apk
Very old to me. And not fully solved.
Two cores? Big whoop! Four cores? Haven't seen one, and our computing center keeps current with the latest generation desktop machines.
But factors of (almost) two or (almost) four speedup are no big deal in the grand scheme of things. Wake me up when they are talking about 10 cores, or 100 cores.
But that is the problem. Our resident computer architecture dude tells us that maybe 10 or 16 cores is an upper limit on account of cache memory or other considerations. To go beyond that they will need another approach -- clusters on a chip? For the low order of parallelism of current multi-core multi-processor offerings, I can't see the payoff in investing a lot of effort into developing, testing, and debugging parallel code.
Multi-process and multithreaded applications abound in the real world. Pull your head from your anus and look around you.
Now, are they going to make things faster in exactly the same way as clock increases? Hell no.
Do they take some thought to implement? Hell yes.
However they are here and have been here for decades.
This is unless you are referring to very, very narrow definition of parallel processing that is more applicable in the scientific than business or home forums - breaking down set, tricky, mathematical problems into multiple chunks.
if you want to do the same thing over and over again (serve web pages, process payment transactions etc) over multiple processors/cores/whatever, threads work just fine, thanks.
I know I'm personally deploying my Web 2.0 social-mashup-o-sphere site in z/VM running on z10.
Sure, it can be a bit tiresome to edit my blogroll in XEDIT, but the parallelism... woooosh! My AJAX just *flies* out of that VTAM, Beowulf clusters ain't got *nothing*on me!
Parallelism is actually pretty easy. You just have to completely change the way you think about programing.
-
Web 2.0 implies HYPE
... Parallelism
Place Web 2.0 and Parallelism inside of a hyper link
Web 2.0
Result?
Parallelism was a hot area when I was in grad school 10 years back. We used to say about Gallium Arsenide -- "Gallium Arsenide is the semiconductor of the future -- always was, always will be." Maybe the same thing is true with parallelism -- paradigm of the future -- it's always useful as a way of getting more work done per unit time, but it has high costs associated with it, so people will only use it if it feels like they absolutely have to.
Parallelism has had broad applicability in graphics. It's definitely useful. But I doubt it's going to obsolete what we can do sequentially.
More developers will be able to write parallel code when there exists the proper tools to support such development:
- a proper parallel debugger which fully makes use of multiple GUI windows
- a test harness capable of slowing down and speeding up threads to trigger race conditions
Seriously, aren't these prerequisites to being able to even talk about developing parallel code?This is just a higher level thinking of parallelism applied to business logic.
This is a time to rethink the business logic--i.e. MBA 's need to start thinking about the behavior of their new-idea systems (i.e. the get rich quick schemes). Hence why this guy is generating buzz that the mechanics of parallel processing has matured enough that we can now have a paradigm change in the business world. IBM has been pushing this the last 2 yrs with its Grid computing initiative. Therefore in the end, it's all about hype and the Benjamins.
At the application and lower levels--these ideas been around and proven for the last 10years.
I do NOT look forward to our parallel overlords.
When the only type of tool we have is massively parallel systems, what kind of problems do you think we will apply that tool to, and what kind of problems do you think we will start ignoring? I would rather see us tackle both kinds of problems.
I suspect, however, we will end up with "the contact lens effect", where someone loses their context lens in a dark alley, then looks for it under a streelight "because the light is better over here".
-- Terry
Actually the way they put the massive memory has nothing to do with the normal "desktop pc".
The massive memory means, that spending several thousand USD you can get a system with 64GB of ram.
And a company can spend hundreds of thousands to get a system with hundreds of GB:s of ram.
And spending quite a lot you can get TB:s of ram, and some companies do that, and they do it for a reason.
Some do it for huge calculations, others do it for running databases on ram. etc...
Those things exists TODAY.
It just opens new business opportunities when huge amounts of ram become available on cheaper systems too.
[cheap as in under 100k$]
©God
Of whether you call it Grid computing, Cloud computing, Parallelism or a whatever, it is making it cheaper to bring software (web based) to market. Instead of purchasing 20 servers and having 10 sit idle while I hope that someone buys my super web thingy, I can boot one grid instance and when and if my thingy starts selling, I can boot 10 more servers up in less than 30 minutes. Then I can add and subtract servers on an as needed basis if I have massive traffic, or if I drop down to only hundreds of hits after the initial hype wears off. It really is nice to see it coming to the web.
"My immediate reaction is "WTF? What kind of moron doesn't make things 64-bit safe to begin with?" Linus
It outperforms most stuff in heavily-parallelized workloads. The legacy of the Scalable POWERPARALLEL. (An IBM supercomputer line that ran AIX.)
I am currently working with a company called 3Tera. We are delivering some web based applications as well as some apps we need to be able to scale up and down extreamly fast. I have managed to be able to build an email server in about 30 minutes. Not to mention that if you have questions, their support folks make you feel like you are paying for an entire data center with their fast and professional responses. I for one welcome our new Grid overlords! :o)
"My immediate reaction is "WTF? What kind of moron doesn't make things 64-bit safe to begin with?" Linus
And we also had Teradata, which had specialized database machines, with up to about 500 disks, with a processor per disk and a master processor to split up workloads, typically spreading out an SQL query across a bunch of disks.
Parallel's always going to be with us, because it's an obvious technique to take whatever hardware's available that generation and build bigger machines by clustering a bunch of them together. The only real difference today is that the parallelism is increasingly moving onto the chips, because it's getting tougher to shrink chip features.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
...it catches on pretty quickly. It is obvious from all the posts here that parallel comp is very old... And if it is that old, yet has never been hot, then why now?
Only 1% know parallel programming? Well, how many people a day get inspired to go pick up a parallel computing book? That has something to do with it. What is it for, and why do I need it?
Personal computing exploded once it was on the scene. So did web development. These things you can start small, and they come to you, as opposed to you having to go actively seek them out. Parallel computing has never revealed itself in anything I've done. I've never came across it or tripped on it in any of project.
Our processors are idle 90% of the time, and they keep getting faster. Most of us don't need parallel computing.
With that said, if you invest in it you're an idiot.
While you might not want to replace your entire disk infrastructure with RAM, there's an intermediate level which is to use Flash. The densities and price/GB are a good bit better than RAM, it doesn't need to stay powered to keep data, and you don't have millisecond-long delays from rotation or seeking, though the throughputs aren't as fast as RAM. The limited numbers of writes that old flash had have been improved a lot, and wear-leveling technology takes care of most of the rest. Operating systems aren't always really set up to use it (Vista supposedly has some capabilities), and you may end up just using it as swap space, but it's still theoretically a big win for some uses.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
So how do you find workloads that can exploit many cores effectively? You can do servers, which can do just fine by sticking each client process/thread onto a single core, or reinvent database parallelism, or run virtual machines since nobody writes their applications securely enough to use Unix-style multiple users any more. Or you can find applications like graphics that parallelize well enough and use a bit of glue to hand of chunks of SIMD work to different cores. There are getting to be fewer and fewer CPU-bound problems that don't fit onto a single processor well. So maybe it's time to start moving more kinds of applications into the same chip - move the graphics off the GPU and back into the main processor, or have different types of cores for different applications.
If we can't find ways to do things like that, it's going to be annoying to chip-makers to have to find ways to make money as Moore's law makes high-speed CPUs cheaper and cheaper. There's a certain amount of Microsoft Bloatware(tm) and gamer framerate-lust that can keep them going, but basically desktop CPUs are already faster than most of us know what to do with. VmWare means that the fast multicore CPUs are getting exploited by people who use them to cut down on the number of servers they're buying by factors of 5-10, though the electricity savings means that you can sell a lot of server cores into the replacement market.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Now the biggest problem of parallelism is actually sharing data, because you share data you need to worry about data corruption and deadlock. So why don't we just don't allow sharing between two processes at all? Yes it might be slower, but it will be alot easier and there is still alot of parallelism can be achieved without sharing data. We know that there are design patterns that don't need to share data, such as the producer/consumer aka pipeline pattern. So why don't we just only use these patterns?
I think we need a parallel programming language that disallow data sharing. It could adopt Actor Oriented Programming, which is a parallel programming methodology with computational entities called actors. The only concern we need to think about is how to pass complex data structures by value to another process and how to minimize data communication. I don't have much experience on Erlang but I think it is a nice programming language to try on.
The advantage of disallowing sharing of data is so that inexperience programmers can write relatively efficient parallel programs without worrying too much about race condition and deadlock etc. Another advantage is that the program you written can be ported onto any number of processors across a network, because if you don't share data there is not much difference whether you will run your program in just one or many computer! I think that having data communication through network protocol is not wasteful, because there are alot of excellent applications do well in parralelism by distributed computing through network. Hence I think the time wasted on data communication between cores in local processors is much less than the time saved on debugging a shared memory parallel program.
I can't really see any advantage of trying to crunch every single algorithms in a program into parallel algorithms, because in that case what is the whole point of multicore processors? Imagine that some day you have a 16-core processor and you are running 16 desktop applications, all of the 16 applications split their procedures into 16 threads and they made full use of your 16-core processor, and each of them finish their tasks in 1 second. What is the net effect then? Is there any more difference than running 16 single threaded applications each on one core? My whole point is that I don't think there is a need to boost performance on an application if the application can finish its task in very short time. Building a few threads in an application to handle different aspect, such as one thread to handle GUI and one to handle processing, that is good enough parallelism in my opinion.
I am currently taking the module of parallel and concurrent programming in my university, and sadly the lecturer only taught us how deadlock and race condition appear and how synchronization techniques such as locks and semaphores work. But the lecturer doesn't teach us anything about how to write a good parallel program, so I'm pretty sure that most of the students that rely on this module cannot write any good parallel program. Anyway please do correct me if I have anything wrong. Thanks.
SaaSaaa? This is getting ridiculous. Really.
$20 mio is pocket change for intel. If that's really all they put into
research of parallel computing then that doesn't seem to rank so high
on their priority list.
Wouldn't surprise me as the market for parallel computing is fairly small
(HPC) when compared to the cash cow sectors (server, consumer).
I think the article is hyperbole. There isn't much need in those
latter markets for parallelism at the hardware level because only
few tasks can be parallelized at that level.