OSNews

Not really, doesn't 4.2 produce C++ code that is ABI compatible with 4.1.x? Just recompile your kernel and glibc (to make yourself feel better) and let the rest phase in.

Does the same apply for an LFS user who is using gcc-4.0.3?

Re-read what I wrote :-P

Where do we download all this code for the Windows(tm) kernel and Windows(tm) glibc? ;-)

Edited 2007-05-16 20:52

deleted

Edited 2007-05-16 21:01

"""
deleted
"""

Slightly confusing thread, isn't it, dimosd? ;-)

Edited 2007-05-16 21:17

>Slightly confusing thread, isn't it

Sleep or more coffee, that is the question :-)

Silly duplicate post. Sorry.

Edited 2007-05-16 20:53

I don't mind waiting if it is on the order of a few weeks, I'm just curious what the normal gap time is. If it is more than that then I'll take the build it on my own route.

Dunno, but it's important? Uniprocessors are clearly disappearing from the compuer market.

There are still a lot of people with single uniprocessor systems. I agree they're disappearing fast.

For myself though - I'm wondering if I should jump on the GCC 4.2 boat earlier or later since my Linux boxes are running older hardware.

I'm not planning to disappear (or upgrade to a multi-core processor) in the near future

My bad - I meant that uniprocessor systems are probably disappearing over time. These systems won't go away completely - they're probably going to be in the minority rather than the majority.

"they're probably going to be in the minority rather than the majority."

Lifespan of a PC 5-6 years

I'm not sure about that. Efficient single cores are perfect for nice tiny little low budget laptops. And that market is still growing.

Years ago that might have been the case, but given how much the die has shrunk, the difference between a single and dual core within the next couple of years will be a matter of a few cents - sacrifice a few cents resulting in ultra crap performance? I doubt OEMs will make that sor tof sacrifice given the dog-eat-dog performance orientated market which exists.

Well, I can't see why not. Because of the nature of your question, I kind of sense you don't know what OpenMP is about.

It's a standardized set of extensions to selected programming languages implemented as compiler pragmas. In theory, your code should be programmed in such a way that compilers that understand those pragmas will generate parallel code automatically, and those who don't will simply ignore such pragmas and generate serial code as usual. You place such pragmas on strategic points on your code and OpenMP will "automagically" emit parallel code to handle those strategic code paths. Things unfortunately aren't so simple, but they usually work pretty well when the data set is easily processed in parallel, for example many classes of graphic and signal processing algorithms, and some classes of physics simulation algos too. And plenty of brute-force algorithms when not implemented naively, but that's almost an oxymoron =P

OpenMP lets you transfer the job of dividing your program into parallel to the compiler, instead of doing it on your own. Some pragmas imply constructs that one might forget to use, like barriers. Which also implies that sometimes those constructs aren't really necessary and OpenMP will produce sub-optimal code compared to hand-tuned threaded code, but that's not what OpenMP is about anyway.

OpenMP is supposed to handle parallelizable data-sets with a somewhat large grain; it seldom does a good job on code that would benefit most of finely-grained parallel tasks.

In a sense, OpenMP babysits the parallel code creation. It really won't do you much good depending on your data set characteristics, and hand-tuned threaded code is probably faster anyway, but for long-term number-crunching on appropriate data sets OpenMP really shines.

For the casual uses, the GCC version of OpenMP will probably use pthreads, and I couldn't really find whether one can use MPI/PVM implementations (which is the one found on many clusters and NUMA boxes), but I find it great already that many programmers will be exposed to OpenMP "APIs" (if they can really be called that); it should at least help those "lazy programmers" writing code they know is parallelizable but don't think it's worth the trouble to re-model their algorithms around threads.


Now, regarding the uniprocessor case: some classes of algorithms can surely benefit from being run "pseudo-parallel", as in many threads being scheduled to run on a given time. For example, branch-and-bound algorithms could be run multithreaded and an eventual bound could be found by a thread earlier than others because it followed a different path; then it broadcasts such information so every thread restart working from that point on. Same thing with other algorithms based on backtracking, depending on the implementation and the goal.

Anyway, parallel code on uniprocessors usually don't hurt, unless shit begin to happen, like cache trashing and consistently following a code path that finishes faster serially than trying to separate cases into threads that execute in some scheduled order. But it's up to the programmer's discretion NOT to attempt parallelization on such cases.

Remember: no magic bullets. No compiler features can make up for sheer lack of competence on the programmer's side. =P


Edit: grammar, and I realized I made lots of assumptions that someone completely unfamiliar with OpenMP won't really understand. So I added a couple sentences to clarify some points, but I'm probably missing stuff, still. Let me know if there are still points you'd like me to clarify even further.

Edit 2: grammar, still =P

Edited 2007-05-16 21:51

I was thinking about that - you and butters are right. OpenMP will probably benefit uniprocessors a bit - especially on I/O limited programs. If OpenMP is smart enough to divide up the threads at the right places, it could improve performance quite a bit.

>OpenMP is all great - but does it benefit to uniprocessors?

Obviously not.

does it benefit to uniprocessors?

Yes. At a high level, a thread is a mixture of computation and I/O. A thread can sprint through a section of math, load/store, and branching operations quite happily. But when it hits a page fault during a memory operation or requests I/O, the thread comes to a screeching halt. It can no longer do anything useful on the CPU, so it goes to sleep, and some other thread is scheduled. On a lightly-loaded interactive system (i.e. a desktop), this is likely be the idle task.

If the process were multithreaded, then the scheduler would have the opportunity to schedule another thread in the process that might be ready to run on the CPU. On most systems--especially on desktops--there's likely to be more threads waiting on I/O than there are threads waiting for CPU time. Multithreading gives the scheduler the best shot at being able to use CPU time effectively, regardless of whether you have one CPU or 1024 CPUs.

Of course, this is a generic argument for multithreading, and OpenMP is just one way of writing multithreaded software. It's mostly a consequence of how Fortran, C, and C++ developed and evolved. For example, the D programming language has mutual exclusion and synchronization primitives built right into the language. Modern interpreted languages have their own multithreading techniques.

In the quest for increased performance and capability, computer systems have evolved to allow workloads to be divided at various levels. The ancient timesharing systems allowed multiple processes to run on the same computer. Multithreading allows multiple threads to run in the same process address space. Virtualization allows multiple virtual computers to share the same physical computer and/or multiple virtual operating systems to share the same operating system image. Every refinement in the granularity of workload management allows us to do more with less and to utilize more powerful computers effectively.

Edited 2007-05-16 23:31