The Daily WTF: Curious Perversions in Information Technology

2006-08-10 Reply Admin

Anonymous:
Ah, CodeProject.

I once got into an argument with an author there. He was convinced that the only time that the stack existed was when an exception was thrown.

O_o

--Tei

2006-08-10 Reply Admin

Sure, had many of those days, but not two straight months of it. Did you comment it? Did that include debugging? Anyway, I wouldn't take it too seriously. 150000 lines of code in two months is not normal for anyone. Any your just a gangsta boastin' if you say its normal for you. But I guess your paying the price now from continued expextation at that rate.

2006-08-10 Reply Admin

Anonymous:
Zygo:
Threads are *slow*. Any OS that actually has a decent thread implementation dies horribly in the marketplace because no software can be ported to or from that OS because the prevailing assumptions are so different.

You mean, like Linux?

Nah, linux pthreads are serviceable but not fantastic. They're certainly not the performance-killing bottlenecks Zygo seems to imply, but they're not even as fast as Win32 threads - mainly because most of the *nix are designed around multi-process over multi-threading, where they far surpass Win32. (One of the reasons for the unfortunate continued prevalence of Apache 1.3.) Maybe it was Solaris that has extremely fast threads, or maybe it was one of the BSDs, I forget. :p

AI0867 · 2006-08-10 Reply Admin

Zygo:

IIRC, in Java up to version 1.3, one-thread-per-connection (actually, two threads if you want bidirectional communication) was the only way you could code such applications. No non-blocking system calls, no select or poll...but the runtime and JIT mechanisms were supposed to make threads really cheap and fast.

unless you're using HotSpot, java bytecode is interpreted, unlike C#.

John Hensley · 2006-08-10 Reply Admin

You can always tell the gangsta coders. They hold the mouse sideways.

hotzenplotz · 2006-08-10 Reply Admin

Zygo:
(...)

Threads are *slow*.

(...)

Threads are decades old, but decent, commercially practical *implementations* of threads (outside of the embedded market) have been available for only a few dozen months.

Which implementation are you referring to?

Zygo:
The Boost library in particular, like many C++ libraries, aims to have *zero* overhead (i.e. the CPU spends zero clock cycles doing anything that isn't absolutely necessary for performing the documented tasks in the spec). Not "low" or "minimal" overhead--zero. Of course they'll never actually achieve that goal, but adding thread support is a giant step away from it.

OTOH *not* adding minimal thread safety (as opt-in or opt-out would be OK of course, if the "opt-granularity" is fine enough, i.e. per object) would mean that the library is pretty much useless for many programmers and teams out there. I do see your point though, and I too whished that there were a way to get rid of the interlocked instructions used in shared_ptr to name just one, but if I have to choose between the overhead of "every shared_ptr is thread safe" vs. "no shared_ptr can be thread safe" then I take the thread safe version every day.

Zygo:
Qt, on the other hand, is a popular C++ library full of wonderful thread-safe code. It also allocates multiple objects on the heap when you construct a simple list iterator--so expensive this is, that Qt itself avoids using list iterators in special cases like lists of one element. It has a very different notion of "high performance" than I do...

Well, the reason the example you give is slow is not thread-safety, but maybe a poor implementation of it, and the (probably avoidable) use of dynamic memory allocation. And probably also a slow memory-allocator (call it "heap" if you will, but a *fast* memory-allocator will be much more that a simple heap). And there are fast memory-allocators out there, using things like per-thread free-lists (avoiding frequent synchronization), per-size free-lists for frequently requested sizes and other fancy stuff that I'm not nearly *gangsta* enough to even think about :)

And finally, when you're talking about things (like threads) being slow, then maybe you should just wave C++ goodbye and embrace java or .NET where you'll get fast threads, fast memory-allocators and all that (almost) for free.

2006-08-10 Reply Admin

Anonymous:

MY GOD!!!!!! How do such STUPID people find work!

Jerry seemed like a nice guy; he had "20 years of C++ experience," which, at the time, was older than C++ itself.

That is a common piece of garbage! I was once asked if I had 5 years or more of experience with VB5, and I told them what I had(LESS THAN 5 years), and said that if ***ANYONE*** said they had more, they were LYING! Even the developer couldn't claim more, as the beta had changed a bit, etc... Still, they seem to ALWAYS want 5 years +, even if the product came out yesterday!

, wasn't joking. Brian, still being a nice guy, explained that you can't use MFC if you ever want to compile something outside of Windows. "Huh," Jerry responded, "I’ve only used Windows and, besides, isn't UNIX based on Windows."

Actually, windows is a stupid imitation of X windows(which ran over UNIX) which came out a year BEFORE M/S Windows! M/S Windows ran over M/S dos(which came out about 4 years BEFORE M/S Windows) which was an imitation of CP/M (which came out over 5 years BEFORE M/S DOS and about 1 year BEFORE MICROSOFT!!!!!!). CP/M is obviously loosly based to some degree on UNIX which came out about 5 years before THAT!

MY GOD! The I.E.E.E. standard predates microsoft by about 4 years!!!!! NOT, WINDOWS, NOT DOS, but the ****ENTIRE COMPANY****

You need to switch to decaf and a healthy dose of Prozac, sweetheart.

tin · 2006-08-10 Reply Admin

WeatherGod:
Meanwhile, a good song to play while reading this post is that rap in "Office Space".

At the risk of stating the obvious (and possibly also somehow getting it wrong), that song is "Damn It Feels Good To Be A Gangsta" by Geto Boys, right?

WeatherGod · 2006-08-10 Reply Admin

Anonymous:
The Original Pimp Player!
[image]

That is SOOOO my new desktop image!

DAMN, it feels good to be a gangsta!

hotzenplotz · 2006-08-10 Reply Admin

Hmmm, this is gonna get long...

Well, I see no WTF in spawning 100 (one-hundret, not hundrets of!) threads - the WTF is spawning an *unpredictable* number of threads - i.e. one per connection. As some already pointed out this is a classic case where one would implement a producer-consumer-queue, with 1-n consumers (workers) and possibly even 1-n producers (message-readers). Maybe even one thread that's just dedicated to block on listen(), then accept(), forward the socket for the new connection to one of the readers and go back to listen(). Or maybe not - would have to do some benchmarking here as I haven't done a dedicated listener thread yet :)

And of course, if the connections were very-much-short-lived (they aren't in this case, I've read that, but let's just assume they were), then creating one thread per connection would still be pretty dumb, since *creating* a thread takes a huge amount of time compared to just doing some context switches or synchronization.

And as far as the "threads are *slow*" comment goes: well, every program that does something that's not absolutely necessary is slow compared to a program that completes the same task without the overhead. So what? Most techniques that ease a developer's live, many of those fancy patterns that make the code so much more easy to understand and maintain, many of those things come with a price: overhead. Be it in execution time or increased use of other system resources. Just think about virtual memory, separate address spaces for different processes, shared memory and cache-coherency in SMP environments, fancy STL stuff, fancy boost stuff -- do you really think all that fancy features come without a price? Well, they don't. And they never will. Still I like them because they limit damage done in case of a critical error, ease the headaches I get when writing code, drastically cut down production times while still yielding the same (or better) quality etc.

Anyways, I *do* think that multi-threading is slower that it'd need to be, especially on windows (probably on other platforms too, but I'm a windows guy and don't know that much of the UNIX world). The most important problems I see here are not with the kernel - the kernel is pretty fast and efficient when dealing with threads - but with the tools & libraries. MSVC's heap implementation for one. Libraries (not necessarily MS' ones) still using a MUTEX when they could in fact use a CRITICAL_SECTION. The still missing TimedEnterCriticalSection function (why-oh-why? this should be SO easy to do - just ignore the initial spinning period and implement the timeout soley when suspending the thread). The missing low overhead "CRITICAL_SECTION style" counterpart to EVENTs. And the list goes on...

But the one big problem that comes to my mind when I think about threads, the one that outweighs the sum of all the others, is: out of 10 programmers who have a good grasp of what they're doing, probably less than 2 really understand multihtreaded programming -- AND -- probable more than 4 don't even get that "wait, I think I'm out of my league here" thought when STILL using threads even though they don't know jack about the matter. In other words: the huge amount of programmers that assume threads will "just work", just like std::sort just works, when in fact, they don't. Duh.

Sorry for being this verbose :)

Some Idiot · 2006-08-10 Reply Admin

AI0867:
Zygo:
IIRC, in Java up to version 1.3, one-thread-per-connection (actually, *two* threads if you want bidirectional communication) was the *only* way you could code such applications. No non-blocking system calls, no select or poll...but the runtime and JIT mechanisms were supposed to make threads really cheap and fast.

unless you're using HotSpot, java bytecode is interpreted, unlike C#.

WTF? IIRC HotSpot wasn't standard until 1.3, although it's worth noting that HotSpot is a Sun product, and there were other VMs and JITs available. We are discussing relatively ancient history as far as managed code goes and comparing Java up to 1.3 with C# shows you are ignorant of said history and/or pushing an agenda. The guys that did C# did so after playing with Java, so C# shares some of it's heritage with with modern Java. Yes, C# is an excellent language, but your comment looks almost as bad as an attempt to compare Boo with B.

And in case you're wondering how I know, read my CV and you'll see that I programmed my first HD media center in Boo on a DEC PDP-7 103 years ago, a media center that never took of because Edison insisted on maintaining full editorial control over what we streamed to it.

Anyway, how's cheap threads going to go with the bling bling?

Another word for "threads" is "duds".

Thanny · 2006-08-10 Reply Admin

Anonymous:
Anonymous:
Zygo:
Threads are *slow*. Any OS that actually has a decent thread implementation dies horribly in the marketplace because no software can be ported to or from that OS because the prevailing assumptions are so different.

You mean, like Linux?

Nah, linux pthreads are serviceable but not fantastic. They're certainly not the performance-killing bottlenecks Zygo seems to imply, but they're not even as fast as Win32 threads - mainly because most of the *nix are designed around multi-process over multi-threading, where they far surpass Win32. (One of the reasons for the unfortunate continued prevalence of Apache 1.3.) Maybe it was Solaris that has extremely fast threads, or maybe it was one of the BSDs, I forget. :p

OS/2 has the best thread implementation that I know of, in terms of performance, and possibly also synchronization. Whenever in doubt about the latter, just surround a block of code with calls to DosEnterCritSec()/DosExitCritSec(). That guarantees that no other thread in the process will get a time slice while the code is running.

Beyond that Windows is certainly better than Linux with threads, at least the NT-based versions.

hotzenplotz · 2006-08-10 Reply Admin

Thanny:
OS/2 has the best thread implementation that I know of, in terms of performance, and possibly also synchronization. Whenever in doubt about the latter, just surround a block of code with calls to DosEnterCritSec()/DosExitCritSec(). That guarantees that no other thread in the process will get a time slice while the code is running.

You probably mean that the thread that holds the lock isn't suspended. If no other thread in that process were to run at all, or even just context switches on CPUs/hardware threads (those which are not executing the thread that holds the lock) were disabled, that would be disasterous for typical multi threaded server applications, even multimedia stuff and some "normal" apps.

Keith Gaughan · 2006-08-10 Reply Admin

Actually it took a day and a half for my desk and development machines to get set up ... But atleast I got the laptop the first day, loaded with the guys source code that I took home to review to learn since I figured we've both be working on the same code.

Don't tell me: the company didn't bother with source control either...

Keith Gaughan · 2006-08-10 Reply Admin

That guy on the left is a meme of his own.

I christen him "green boa dude"!

2006-08-10 Reply Admin

Anonymous:
Anonymous:

You need to switch to decaf and a healthy dose of Prozac, sweetheart.

Are you Gary, or Gary's wife? Just curious....

I don't generally drink coffee, and I am fine in the depression department.

2006-08-11 Reply Admin

yay! threads... raider i feel your pain man

even for the most wizard programmer with the best programming and design practices threads are absolutely nightmares on single processors, not to even get into multi-processor beasts - debugging them is a downright pain in the ass.

CAPTCHA: perfection

As my boss told me 25 years ago - you can't debug multi-threaded code - you have to design it correctly in the first place.

2006-08-11 Reply Admin

Anonymous:

Also, almost every article on there for .NET is lifted from MSDN or from another site, without any any credit given.

Well, report the article and it will be removed. The Guys at Code Project are pretty quick at getting rid of copyright infringing material.

Also, as a general thing, if the article is crap vote it down and leave a message in the forum at the bottom. If it gets enough low votes it will eventually get put in purgatory. (Purgatory is the section where really bad articles go, just in case the author has a change of heart and actually produces a good article)

And anyone daft enough to follow blindly any article that is unedited or in purgatory should be shot.

Rodyland · 2006-08-11 Reply Admin

Alex Papadimoulis:
I don't like to pick on specific companies or sites. But I figure that this reply will be burried far enough in the comments that a clue should be ok. The website in question (and I should note that I get a LOT of submissions directly linking to this site) starts with the the letter "c" and ends with "odeproject.com"

Somehow, as soon as you described the site in the OP, I thought to my self: c0d3pr0j3c7.c0m

And it's nice to be validated. :)

I'm on their mailing list - sometimes they have interesting stuff to.. ummm... borrow... but the signal to noise ratio is Waaaay low.

2006-08-11 Reply Admin

Anonymous:
What chance does a young man, having no formal training, being self taught in all aspects have when his favourite coding site is rubbished by his favourite "how not to do things" site!

It's not easy. Your best chance is to follow discussion fora and Usenet newsgroups where people regularly (and constructively) criticise each other's code. You'll gradually get a feel for which arguments make sense and who knows what they are talking about.

The other thing is to look critically at everything you borrow. Unless you are using modules that are widely recommended by people who you have discovered to be trustworthy, you need to make sure you know what every line is doing, and why.

2006-08-11 Reply Admin

Is it just me or is this not valid c++ code?

public int ProcessIncomingMessage
  (int messageId, int messageType, char* message)

shouldnt it be like this?

public:
int ProcessIncomingMessage
  (int messageId, int messageType, char* message)

2006-08-11 Reply Admin

Anonymous:
Anonymous:

Also, almost every article on there for .NET is lifted from MSDN or from another site, without any any credit given.

Well, report the article and it will be removed. The Guys at Code Project are pretty quick at getting rid of copyright infringing material.

Also, as a general thing, if the article is crap vote it down and leave a message in the forum at the bottom. If it gets enough low votes it will eventually get put in purgatory. (Purgatory is the section where really bad articles go, just in case the author has a change of heart and actually produces a good article)

And anyone daft enough to follow blindly any article that is unedited or in purgatory should be shot.

Of course I've reported articles. Problem being, bad articles keep popping up there like a plague. The S/N ratio there is 5/95%. That makes it awfully hard to actually find good articles there. After a while, it's just not worth it.

2006-08-11 Reply Admin

Those who say that 100 threads per second will grind a computer to a halt: what kind of lame operating system do you have? Even my tired old laptop with Windoze handles 10,000 thread creations and destructions per second. So 100 threads/s would consume one percent of CPU time.

Are you sure you are measuring your performance instead of just ass-u-&-me-ing?

Sure thread creation is slow but it isn't that slow. I have implemented web services with sustained loads of several hundred requests / s. I'd probably use a thread pool if I needed a thread per request, but I'd profile before doing that. Just so that I can direct my optimization effort to something that matters first. And so that I don't fall for any outdated programming myths.

2006-08-11 Reply Admin

Raider:
You must have overlooked the reply I put in that stated the code example Alex used, is just an example to illustrate the scenario, it is not an actual code snippet from the program.

So... the "example" was something that Alex made up, inspired by your story about what the code was like. And it doesn't actually demonstrate the thing that made you go WTF.

How common is this? So far I'd innocently assumed that the WTFs were real code, found in production systems. I'm about to lose my faith here.

2006-08-11 Reply Admin

Anonymous:
Actually, Windows is a direct crib of Mac O/S which in turn is a direct crib of the Xerox Star system, which Steve Jobs *borrowed* heavily from when he was given a demo at the PARC centre.

Well actually the Mac O/S was a development of the Lisa, which was based on Xerox Star.

Anyone else remember the Lisa? I sometimes wonder whether the one I used briefly was the only one to get to Europe. I've never met anyone else who used it.

2006-08-11 Reply Admin

It's not the code snippet but the fact he didn't know what he was doing ("Unix is based on Windows").

As for quality, look at the maturity of the replies in this thread...

2006-08-11 Reply Admin

Anonymous:
Ever had one of those moments where you sat down, got an idea, and started writing code, and before you knew it the entire work day had gone by and you had generated 10000+ LOC ?? ... Happens quite often, especially on new projects where the entire design and purpose of the app is already laid out and it boils down to just writing the code.

10,000 lines of new code in one day !!??? Methinks you are jangling my nurburdangs !

2006-08-11 Reply Admin

Anonymous:

10,000 lines of new code in one day !!??? Methinks you are jangling my nurburdangs !

WTF?!

2006-08-11 Reply Admin

Anonymous:

Actually, Windows is a direct crib of Mac O/S which in turn is a direct crib of the Xerox Star system, which Steve Jobs *borrowed* heavily from when he was given a demo at the PARC centre.

You're quite correct, of course. I was referring more to Windows' ancestry than its parenthood. But you're right, that's not what I said.

TeeSee · 2006-08-11 Reply Admin

R.Flowers:
Anonymous:
Just so I know to avoid it, which site is "known best for its presentation of astonishingly low-quality, unedited articles and code samples"?

I honestly thought this was a sly reference to TheDailyWTF.com. :) I mean, how awesome would it be if some clueless coder actually copied code (try saying that 5 times fast) from here, and it eventually showed up... back here?

Clueless Coder Copied a Class with Crashy Code
A Class with Crashy Code Clueless Coder Copied
If Clueless Coder Copied a Class with Crashy Code
Where's the Cranky Coder that we hired to fix it?

2006-08-11 Reply Admin

Anonymous:
Just so I know to avoid it, which site is "known best for its presentation of astonishingly low-quality, unedited articles and code samples"?

It's called "The Daily WTF"

TeeSee · 2006-08-11 Reply Admin

Anonymous:
oh.. and btw - this is the way i deal with multiple connection servers

I loop and check if data is ready on the listen connection, if so i accept the connection and add it to my connection list. I then loop through the connection list checking for data ready and processing any communication if data is ready.

pseudo-code

while (1)
{
     check-for-connections and accept them
   loop on connection list
     {
          check for communications and process
     }
    check for shutdown command - if bound break
}
disconnect all clients politely.

If i ever get into a large enough connection volume situation I would create a pool of threads where each thread is assigned a certain number of connections to handle.

Very, very bad. Polling is a big no-no. The correct way is this:

for(;;)
{
event = wait_for_something_to_happen();
handle_what_happened();
}

Here, you don't waste CPU time looping around when nothing's happening. epoll or select is preferred, probably in that order.

How do you handle signals (e.g. 'shutdown')? In the signal handler, write a byte to a special command stream, which is handled by select(). This guarantees you don't get 'lost notifications' (last time I checked, pselect didn't provide such a guarantee).

This doesn't multithread easily, and it shouldn't be multithreaded on single-processor machines anyway. If you code it properly, it should never block except with select(), so multithreading won't give you any advantage (unless it takes ages to find out what actually happened, which is why you should use epoll when you can). If you did multithread it, you'd have to try hard to avoid concurrency issues anyway.

InfoSeeker · 2006-08-11 Reply Admin

It is just another case to demonstrate the saying that "There is no dangerous C/C++ functions only dangerous C/C++ programmers".

It is a case of those who need to know what to check do not and those that need to know what to do, do not and when they tangos together, you get this kind of mess.

While Google and the Internet are great tools to locate materials but far too many people fail to spend time understanding the technology/principle behind before applying the discovery is a hotch-potch manner. These are often called Compiler-Happy code!!

IT industry is full of these kind of con-man/woman.

2006-08-11 Reply Admin

Man, aren't you full of yourself (the guy in charge here, that is). I don't think there's any programming site on the net that doesn't have it's own share of crappy code submitted by its users. Sure, there are really crappy articles on CP, and there are also many more that are well written and even some real gems. I'm sure you'll find similar ratios on most of the decent programming sites.

In the end, I go there looking for techniques rather than outright source code, but if the source code that accompanies the technique is decent, I might use it, at least as an example.

2006-08-11 Reply Admin

It seems like a strange leader-follower implementation with no inactive followers.

A leader/follower pattern works as follows:
- You have a few worker threads.
- Only one thread at any time is listening to incoming requests (or whatever). This thread is called the leader.
- The other worker threads are either processing requests that came in earlier or are idling. Those are the followers.
- As soon as the leader receives a request he makes someone else a leader and immediately starts processing that request. He has become a follower now himself.

The good thing about this pattern is that there is no immediate thread switch, because the one listening to an incoming request is also the one immediately processing that request.

stevekj · 2006-08-11 Reply Admin

Anonymous:
Raider:
You must have overlooked the reply I put in that stated the code example Alex used, is just an example to illustrate the scenario, it is not an actual code snippet from the program.

So... the "example" was something that Alex made up, inspired by your story about what the code was like. And it doesn't actually demonstrate the thing that made you go WTF.

How common is this? So far I'd innocently assumed that the WTFs were real code, found in production systems. I'm about to lose my faith here.

You must have missed my earlier complaint on this very topic. I can almost understand why Alex needs to make up his own code, to avoid getting into copyright troubles and whatnot. But he also makes up the background stories, most of the time (not all of the time), without telling you when the material is made up and when it isn't. So it's not so much TheDailyWTF as TheDailyMightHaveBeenAWTFIfItHadActuallyOccurredButItDidntAtLeastNotAsShown.

tlg · 2006-08-11 Reply Admin

Raider:

The only way I'd ever do one thread per connection is if there would be less than 10 connections on a single or dual core/cpu system and the connections have to be synchronous.

Amen to that. I was really hoping someone else thought this because I was beginning to doubt myself! As for Zygo saying "threads are *slow*" (later), that's a bit like hollering "today is Sunday!" - sometimes it's true, but a lot of the time it's not. Here we have a prime example of where threads are slow but cmon - it's been posted here on WTF so it's meant to be awful ;) My line of programming is involved in real-time systems and without threads, implementation details would take over and render a project ridiculously comvoluted. That's not to say that my predecessors didn't try...

Off topic, I haven't posted for a while but someone else started using this nick (obviously before I registered it) and pissed a few people off in the worst possible way - they joined a thread on the c++/java holy war. It wasn't me.

Please don't start up that argument again... ever. Lets all just aecept that brainf**k is the future.

2006-08-11 Reply Admin

Is THAT what it is? I thought it was the A/C leaking.

captcha: Shizzle. Ma nizzle?

2006-08-11 Reply Admin

Zygo:
The other month I reviewed some code from an invertebrate Windows developer who is so reliant on VisualDevThingy that he is single-handedly porting our flagship Linux application suite to Windows just so he can use VDT to edit code.

Inverterbrate? You know a dude without a backbone who knows how to port? Remind me to invite him to my next party.

Oliver Klozoff · 2006-08-11 Reply Admin

Anonymous:
Ah, CodeProject.

I once got into an argument with an author there. He was convinced that the only time that the stack existed was when an exception was thrown.

Also, almost every article on there for .NET is lifted from MSDN or from another site, without any any credit given.

Duh, of course that's not true. The stack is also created when you call "new StackTrace()" (in the System.Diagnostics namespace).

2006-08-11 Reply Admin

The MSDN Library

2006-08-11 Reply Admin

Anonymous:
Sure, had many of those days, but not two straight months of it. Did you comment it? Did that include debugging? Anyway, I wouldn't take it too seriously. 150000 lines of code in two months is not normal for anyone. Any your just a gangsta boastin' if you say its normal for you. But I guess your paying the price now from continued expextation at that rate.

Giving the benefit of the doubt.... let's assume it was July-August (2 consecutive 31 day months). And, let's assume a mean workday of 12 hours (allowing for 10 hours a day on weekdays + longer on weekends - breaks for eating and pooping)

150000 LOC / 62 days / 12 work hours / 60 minutes = 3.4 LOC / minute.

Obviously, things would go faster if the eating breaks included lots of olive oil (cuts down on the time needed for the pooping breaks).

I think we all know long work hours at crunch time (I was on a project with 2 months of 100-110+ hour weeks), but I think most of us will readily admit that mental capacity starts to drop off quickly at that sort of pace.

I smell a slight exageration... plausible though.

2006-08-11 Reply Admin

3 days on the job? Almost all of these posts have a guy working for 3 days on the job.....it's time to mix it up a bit....post some WTF's that occur on day 1.....and day 4

drdamour · 2006-08-11 Reply Admin

Anonymous:

Anonymous:
Sure, had many of those days, but not two straight months of it. Did you comment it? Did that include debugging? Anyway, I wouldn't take it too seriously. 150000 lines of code in two months is not normal for anyone. Any your just a gangsta boastin' if you say its normal for you. But I guess your paying the price now from continued expextation at that rate.

Giving the benefit of the doubt.... let's assume it was July-August (2 consecutive 31 day months). And, let's assume a mean workday of 12 hours (allowing for 10 hours a day on weekdays + longer on weekends - breaks for eating and pooping)

150000 LOC / 62 days / 12 work hours / 60 minutes = 3.4 LOC / minute.

Obviously, things would go faster if the eating breaks included lots of olive oil (cuts down on the time needed for the pooping breaks).

I think we all know long work hours at crunch time (I was on a project with 2 months of 100-110+ hour weeks), but I think most of us will readily admit that mental capacity starts to drop off quickly at that sort of pace.

I smell a slight exageration... plausible though.

in Brian's defense

while(true){

if(socket.ready()){

socket.read();

}

that was 5 lines in 10 seconds

2006-08-11 Reply Admin

Alex Papadimoulis:
Raider:

Anonymous:
Just so I know to avoid it, which site is "known best for its presentation of astonishingly low-quality, unedited articles and code samples"?

I don't think I'm allowed to post on here what sites he found the code snippets on without getting Alex in trouble, but feel free to email the address attached to my profile here :)

I don't like to pick on specific companies or sites. But I figure that this reply will be burried far enough in the comments that a clue should be ok. The website in question (and I should note that I get a LOT of submissions directly linking to this site) starts with the the letter "c" and ends with "odeproject.com"

HA! I knew it! That's the first site that came to mind.
I'm glad I'm not the only one who thinks that site is full of more turds than the NYC sewer system.

2006-08-11 Reply Admin

Anonymous:
Anyone else remember the Lisa? I sometimes wonder whether the one I used briefly was the only one to get to Europe. I've never met anyone else who used it.

I used one at Loughborough University, around 1982. I had to program it in Basic.

2006-08-11 Reply Admin

drdamour:

in Brian's defense

while(true){

if(socket.ready()){

socket.read();

}

}

that was 5 lines in 10 seconds

That's why I only said it smelled like a slight exageration. It depends on if he's counting physical lines or logical lines, if he's using K&R or otherwise, if he's counting comments (if he commented) and if those are on their own lines or otherwise. Still, not every line of code is as simple as above, and everyone is going to have a diminishing return on productivity at some point.

Your block of code above is still isolated, you'd need to account for things like moving your cursor around, opening and closing files, test builds, checkins / checkouts, finding definitions. Granted, in a shorter period of time, things will be more recallable and things go faster if there's no communication involved (only in one person's head) and if you're disciplined enough to not check the daily wtf, etc. A good IDE, intellisense, refactoring tools, background compile, etc would all help... and it depends on physical line count, coding standard, etc.

Accounting for physical line count and 30% "empty" space (blank lines, braces), you only need to hit a 2.35 PLOC / minute sustained rate.

GoatCheez · 2006-08-11 Reply Admin

drdamour:

in Brian's defense

while(true){

if(socket.ready()){

socket.read();

}

}

that was 5 lines in 10 seconds

Oh yeah, also in his defense... lol.... I was doing a side-project where I was using alot of Win32 API calls in a control I was making in C#. I was also utilizing the OpenGL library. To create the class for the imports, I simply cut and pasted gl.h, and parts of glu.h, then did some find-replaces and a little touch up work... Not hard, and not much effort. I also did that for parts of winuser.h... Took less than half an hour, and gave me thousands of lines of code...Technically, they weren't logical lines, but it was code lol ;-P

2006-08-11 Reply Admin

Raider:
Anonymous:
Raider:

Ok, let me straighten everything out now ...

It did *NOT* spawn a new thread for every *message*, it spawned a new thread for every *connection* ... A connection could send millions of messages, or only a few messages, could be online for a day, or for a year ...

The problem is it created hundreds of threads, period ... It doesnt matter if they would be destroyed a second later, or a year later ... Anyone that writes an app that spawns one thread per connection, and leaves them running, anticipating hundreds, to thousands of connections, really needs to go back to the drawing board and learn about non-blocking sockets, or select(), or some other form of socket management.

I agree with, and have used worker threads when handling massive quantities of data (Note: We're talking millions upon millions of transactions going through this app daily), but to spawn that many is a sure fire way to make anyone with half a brain about C++ gag.
public int ProcessIncomingMessage
  (int messageId, int messageType, char* message)
{
  //spawn a new listener so we can process this
  int h = CreateThread(
    NULL, 0, ListenForMessage,
    (void *)this, 0, NULL);

  //now process the message
How is this not spawning a new thread for every message?

I mean, the method name is "PrecessIncomingMessage" not "AcceptConnection" or something like that. There's a comment there that says "now process the message" after the new listener is spawned.

What if messages arrive over a UDP socket? That would be fun.

Captcha = clueless.
You must have overlooked the reply I put in that stated the code example Alex used, is just an example to illustrate the scenario, it is not an actual code snippet from the program.

Yeah, I missed that. I get it now.

hotzenplotz · 2006-08-11 Reply Admin

Anonymous:
Those who say that 100 threads per second will grind a computer to a halt: what kind of lame operating system do you have? Even my tired old laptop with Windoze handles 10,000 thread creations and destructions per second. So 100 threads/s would consume one percent of CPU time.

Are you sure you are measuring your performance instead of just ass-u-&-me-ing?

Nobody is saying "grinding a computer to a halt" - that's just your exaggerated interpretation so you can post this utterly meaningless wise-ass comment of yours.

Thread created + destroyed: ~7 700 ops/sec
Very simple producer-consumer queue (1 producer thread, 1 consumer thread): > 85 000 ops/sec (even with queue-limit = 1)

No real work per "operation", system is a 2,8Ghz P4 Northwood w/ HT enabled, XP SP2. MSVC .NET 2005, release build, full optimizations.

BTW: without the (very unrealistic) high lock contention (or just with a properly set spin-count - I just used 4000 which is the number the MSVC heap manager uses) the producer-consumer queue can do > 600 000 ops/sec. Now compare 7.7 to 600.

Deal with it, creating threads is *slow*. Duh.

Flossin' My Threads

Leave a comment on “Flossin' My Threads”