Today is the day most software turned to "garbage"...

Quote:

---

Originally Posted by TheCPUWizard

This is why I am disappointed (but not at all suprised that the MAJORITY of people who have responded to the poll answered "I dont know how". I really wish I could sample THAT category and ask if they had completed an education in programming at a school or other institution.....

---

Not yet, and I have not taken any modules with a focus on parallel processing, though I certainly have taken several that touch on the topic, but not enough for me to dare claim that I know how to design for it (and I probably would not confidently make such a claim even after I graduate).

I would have covered more of this as a hobbyist, but the current lack of support for parallel processing in standard C++ is something of a hindrance, though I am partly to blame for my reluctance to embrace more of Boost and POCO.

Quote:

---

Originally Posted by TheCPUWizard

That (along with Ahoodin's post) is there part that does get me "upset" (when seen in professional developers).

---

Alright what did I do?

Sorry to be OT, but I thought I would respond to a question raised in the thread.

Quote:

---

Originally Posted by Joeman

So I vote not to worry about threading

---

I vote that people think for themselves.:cool:

Quote:

---

Originally Posted by Joeman

unless you do lots of loops that can be broken out of sync.

---

Huh? This part of your sentence is not so hot and could use a better explanation.

Quote:

---

I will wait until c++0x threading library comes out to consider it further :D

---

Why wait when you can do it with a worker thread, using proper synchronization.

Since I use manly c++, I worry about the compiler optimizing things to which will produce race conditions. Sure you can use violate, but what if you forget it? You will be so confused and it will take you hours to debug. Also I know how to write for different threads and I don't like it. Perhaps intel provides a cleaner way, but I am sure intel won't provide it for free. I like to keep my money if I don't need to spend it.

Multi-Threading your app can be very dangerous and time consuming with little payoff, if you app really isn't for critical processing time. Let's not mention on how sloppy your code can get when trying to pass things off onto others cpus.

Quote:

---

Originally Posted by ahoodin

Quote:

---

Originally Posted by Joeman

unless you do lots of loops that can be broken out of sync.

---

Huh? This part of your sentence is not so hot and could use a better explanation.

---

I am saying keeping your variables in sync is a hard task due to race conditions, so it is best if you don't have to worry about such a mess... like not trying to sync your data with mutexes because even mutexes can become unsync due to unpredicted conditions. Once you prefect your sync, sure you can access your variables okay...

Quote:

---

Originally Posted by ahoodin

Why wait when you can do it with a worker thread, using proper synchronization.

---

Because the compiler can do things you can't do... and will never ever beable to do. I am waiting for the ATOMIC template...... wonder why?

Quote:

---

Originally Posted by ahoodin

Alright what did I do?

Sorry to be OT, but I thought I would respond to a subtopic of the thread.

---

1) Hyperthreading as a specific technology has Nothing to do with it. In fact hyperthreading provides much less performance improvement than additional cores.

2) Using some actual application benchmarks [I can post the details if desired) I recently tested a moderately complex application that was CPU intensive.

Code:

---

Single Core no-HT @3.2GHZ = 3.8 seconds
Q6600 Quad @2.4 GHZ = 1.8 seconds (theoretical best = 1.27 seconds)
i7 920 - Quad with HT @3.0GHZ = 0.85 seconds (theoretical best 0.51 seconds)

---

This is on code which has not had structural changes in over 5 years.

This clearly shows that a core is better than a hyper thread..but more importantly.

As a consumer who just spent approx $1000 on a system upgrade, would you rather see a 6% performance decrease (because the developer didnt make best possible use of available processors) or a 4.4x (440%) increase

What will YOUR customers experience when they upgrade their hardware to a Kiefer [32 cores!!!] and are running the CURRENT version of your software?????

Quote:

---

Originally Posted by TheCPUWizard

1) Hyperthreading as a specific technology has Nothing to do with it. In fact hyperthreading provides much less performance improvement than additional cores.

---

Ok point taken here. I am seeing it now.

Quote:

---

Originally Posted by Joeman

Since I use manly c++, I worry about the compiler optimizing things to which will produce race conditions. Sure you can use violate, but what if you forget it?

---

A. You can turn compiler optimizations off.
B. You can use volatile to make sure it doesn't optimize parts out.

Quote:

---

Originally Posted by Joeman

I am saying keeping your variables in sync is a hard task due to race conditions, so it is best if you don't have to worry about such a mess... like not trying to sync your data with mutexes because even mutexes can become unsync due to unpredicted conditions. Once you prefect your sync, sure you can access your variables okay...

---

I am sorry but mutex, and semaphore are used successfully across platforms. This argument is just false.

Sure mutexes work...... like i said... only if you perfect them.. i did mention about violate...

who wants to turn optimization off? omg... that is like really stupid. you missed the point. you want slower?

Quote:

---

Originally Posted by Joeman

i did mention about violate...

---

I think this is a miscommunication because you both mean volatile instead of "violate" or "voletile".

Quote:

---

Originally Posted by Joeman

Sure mutexes work...... like i said... only if you perfect them.. i did mention about violate...

who wants to turn optimization off? omg... that is like really stupid. you missed the point. you want slower?

---

You missed my point. The point is that compiler optimizations can be dealt with properly. And I am sorry but there are alot of successful multi-threaded applications out there. Just because you didnt write one and don't know how still doesn't make this correct.

I do know how they work and I do know when to use them, but 93% of code can't be offloaded... easily.

If you start naming the apps that use multi-threads, you will find out they need all the speed the can get... like video processing, physics and etc.

Most apps won't need to worry about that unless they bottleneck one processor for more than 4-15 secs.

Quote:

---

Originally Posted by laserlight

I think this is a miscommunication because you both mean volatile instead of "violate" or "voletile".

---

I like to use the "violate" keyword so that the compiler will randomly generate code that is non-compliant. :D :D :wave:

Quote:

---

Originally Posted by joeman

Sure mutexes work...... like i said... only if you perfect them..

---

There is no need to "perfect" or do anything to a mutex unless there is a bug in the compiler/library.

If by chance you meant "you have to use them correctly", then that applies to EVERY aspect of programming regardless of language, platform, threading, or anything...

Fundamently it is no different than sawing that aaddition and assignment only work if you properly hold the shift key (or not) while typing them in... :eek::eek:
(and yes, I have actually had that condition slip into code that made it to the QA department :blush::blush:)

Yeah I meant volatile :D

Yeah I meant by the programmer not messing up mutexes since they can get difficult to use properly. Every newb will screw it up many times before they get the ideal where the fault is coming from. That is what I meant by perfect. I also would recommend using CreateMutex and not trying to create your own :).. and alone forget volatile :(

Honestly, I don't see the big deal in programming for multithreading/parallel processing.

Sure if you explicitly manage the locking and unlocking of the synchronization objects (like cs or mutex), it can be a bit tedious, but if you create some simple helper classes and use RAII, it can be very straightforward.

Quote:

---

Originally Posted by Arjay

Honestly, I don't see the big deal in programming for multithreading/parallel processing.

Sure if you explicitly manage the locking and unlocking of the synchronization objects (like cs or mutex), it can be a bit tedious, but if you create some simple helper classes and use RAII, it can be very straightforward.

---

At a strategic level (large work items, a number of worker threads) it is not a "big deal".

At a more granular level, it becomes much more of a thought process.

Consider a simple application: There is a List structure with 8,000 lines of text. You need to determine which lines contain combinations of 8 key phrases. And produce the list of all combinations of string according to which of the 256 possible sets. You are on a machine with 8 "real" cores [2 CPU x 4/per]

Would you split the list into 8 chunks of of 1,000 strings?

Would you process the same string on 8 different threads (one per phrase)?

Would you take some other approach?