Slashdot Mirror
Is Profiling Useless in Today's World?
rngadam writes "gprof doesn't work in Linux multithreaded programs without a workaround that doesn't work that well. It seems that if you want to use profiling, you have to look for alternatives or agree with RedHat's Ulrich Drepper that "gprof is useless in today's world"... Is profiling useless? How do you profile your programs? Is the lack of good profiling tools under Linux leading us in a world of bloated applications and killing Linux adoption by the embedded developers? Or will the adoption of a LinuxThreads replacement solve our problems?"
The Interstate went on mile after uneventful mile, a perfect ribbon of black cutting the desert before me. The car's air conditioner kept us cool while outside the world sweltered. Beside me, my wife dozed and in the back seat, my son did the same. If I paid attention to the road and my surroundings, I would go mad with boredom. In the cool comfort of the car I let my mind wander to visions of sexy women, perfect smooth butts, firm flawless tits, and downy soft pubic mounds. I had a raging hardon and my hand would occasionally wander to it and give it a tug or a squeeze.
All the action in my shorts eventually brought on a seething need to relieve my bladder. A sign said there was a rest area in five miles. I needed it. I took the rest area exit, pulling first onto a side road and then into the parking lot at the rest area. My son still slept and my wife opened her eyes, nodded when I said I was going to take a leak, and closed her eyes once again. I got out of the car, locked it and headed toward the men's room.
All of the urinals were full so I walked to the last of five stalls and entered. As I did I noticed a hole in the wall leading into the next stall. Out of curiosity I leaned down a bit to look at the stall's occupant and saw his hand, wet with cum, slowly working over his semi-flaccid wet dick. He must have noticed my leaning because he reached out and ran his finger around the edge of the hole. An invitation if ever I saw one. I dropped my shorts and shoved my dick through the hole. The guy was instantly on his knees, rubbing my dick around his face, which I could feel was wet. I assumed it was with other travelers' cum. He soon tired of this sport and started licking the underside of my cock. I wanted him to suck on my balls as well, but the hole was far to small for my balls to fit into it along with my dick.
He finally opened his mouth and began sucking my dick in earnest. It felt great, but I still had a burning need to fulfill. It stuck me then that most people who would enter this stall were folks like me, who had been on the road for hours and needed to piss really bad. This guy sucking my schlong must realize this as well, so I concentrated and let loose with just a small stream of pee. The guy swallowed and removed my dick from his mouth just long enough for a single word to work its way up from deep within him, "More," before shoving my cock back in.
It had been years since I had peed on or in anyone, never being able to get my wife interested in it. I let loose with a slow steady stream of golden liquid which the freak in the other stall greedily drank. Peeing on someone is a visually exciting thing for me though and the stall wall was in the way, so while I continued to pee I slowly pulled my dick back through the hole in the wall. The guy was freaking, he didn't want to miss a drop and tried to hold onto my dick with his mouth.
"Don't worry," I whispered, "you can have it all, I just want to see it." He seemed to understand and let my dick slowly slide from his mouth, which he pressed against the stall wall, covering the hole. I pulled my dick completely from his lips and watched the yellow stream arch into his open mouth. I watched his mouth fill repeatedly with my piss, then it would close slightly as he opened his throat and swallowed. He loved it, every drop of it and so did I. My bladder had really been full; he must have drank at least a quart of my piss.
The stream began to waiver and wane and I moved my dick back up to the hole and his waiting lips. Finally the golden stream stopped flowing; he licked the end of my dick with relish, kissing the head and trying to ram his tongue up my pisshole then started to move back away from the hole in the wall. I let loose with the small amount of piss I had been saving and, from the sounds he made, I got him right across the face with it. I rasped, "Not so fast slut, wash it down with my cum." He stayed on his knees and sucked my cock back into his hungry mouth.
He nibbled at the underside, ran his tongue around and around the head. He worked his mouth up and down my shaft, turning his head left and right, slobbering over my cock like a real pro. Sooner than I expected I could feel the cum in my balls making its way up the shaft of my dick. I jerked it from his mouth, rapidly stroking it with one hand and fondling my balls with the other as I shot load after load of hot cum into his waiting mouth. After five or six massive spurts I shoved my dripping dick back through the hole and into his mouth, letting him suck the rest of the cum out of me. He kept at it until my dick shrank down to a limp hunk of flesh. I finally eased it from his lips and sat down on the toilet.
I knew I always have to piss soon after cumming and didn't want to have to stop at the next rest area so I waited for the need to overtake me again. By looking at his feet I could tell that my friend in the next stall was sitting down too. I listened closely and could hear people pissing at the urinals. Nothing makes you have to go like the sound of others pissing away. I could feel the urge beginning in me. A minute or two more and I would be ready to piss a decent load.
I suddenly heard dribbling sounds like a woman peeing coming from the stall next to mine. I knew I had seen a dick on this guy so I leaned down to the hole to take a look. He was a guy all right, a young guy in his late teens, maybe early twenties. And he was peeing, but his dick wasn't aimed into the bowl, but rather straight up . He was totally nude and his piss was hitting him in the chest, running down his stomach in golden rivulets, and dripping off his crotch to dribble into the bowl. He must have noticed me at the hole, because he looked up at me, mouthed the words, "Thank you lover," ran his tongue around his lips, and then leaning his head down, began to pee into his own mouth. God, what a sight. My dick was a steel bar again as I pounded it with my fist and watched this guy chow down on his golden fluids. After ten seconds or so, he leaned his head back, closed his eyes, and empties the rest of his bladder onto his chest and stomach.
I sat back down and began pounding my cock in earnest, making loud slapping noises. A few seconds later I noticed a tongue sticking through the hole. I stood up and eased my dick back into that now familiar mouth which I quickly filled again with another load of my cum. I dropped to my knees and shoved my tongue through the hole and into my lover's mouth. He used his tongue to push forward the cum he had not yet swallowed and I lapped it up and swallowed it down. I then began licking around his lips tasting the tangy piss that still coated his face. He pulled his face back from the hole and as he rose to his feet and shoved his dick on through he whispered, "I got a little bit left for you baby." I hungrily sucked his small dick into my mouth as it began to spew forth its golden juice. I swallowed two delicious solid blasts of amber love straight from his sticky cock. I sucked the last dribblings of hot piss from his dick, licked it clean and he pulled it back through the wall. My head was spinning, as I stood up, turned, and emptied my bladder in the toilet, pretending it was my lover's mouth. Finished, I pulled up my shorts and exited the stall.
There were two guys waiting, lined up outside the stall as I left who smiled great big shit-eating grins at me as I opened the door. One was a beautiful, muscular black man with a massive bulge in his shorts I couldn't take my eyes off of. As I tried to move from the door he moved towards it and we bumped into each other. My hand was down by my side and went straight for his crotch, squeezing a wonderful mass of hot meat. I looked into his eyes as he looked into mine. He took my hand in his and pulled me into the stall with him.
He pulled me to him and kissed be hard on the lips, pressing his tongue deep into my mouth, possessing it. My hands found the waistband of his shorts. I pulled them and his silk underwear down. He let loose of me, smiled and reaching down, took his shorts and underwear completely off and set them neatly on top of the toilet. I looked at his cock in a daze. It was beautiful, already long and hard, black as coal except near the head where it lightened a bit. It was a magnificent male tool thrusting out proudly from a patch of wiry black pubic mane. Below it hung a scrotum sac of equal beauty and proportions. I fell to my knees in subservient awe hefting his massive black balls in my insignificant white hands as I opened my mouth in an effort to impale my face with his gorgeous black fuck stick.
He recognized that his proportions were daunting, and tried to go easy on my small throat, but I would have none of that. I shoved that black monster down my throat, gagged, removed it, and shoved it down again. When it hit the back of my throat, I swallowed hard and the head slid in. I pressed forward and felt inch after beautiful thick inch slide delightfully down my gullet. I had no idea how big his dick was, ten inches, twelve inches, I just don't know, but as I buried my nose into his pubic patch I knew it was all inside of me. He looked down at me lustily and whispered, "Suck it sugar, suck it like no bitch can." I did my best, making love to that beautiful ebony phallus with every ounce of strength.
He sat down, just the top of his hard buns on the edge on the toilet, spread his legs wide open for me, placing one leg up on the toilet paper holder. I fell to all fours and licked him from dickhead to balls. I sucked on his balls, taking each one into my mouth, they were as big as hard-boiled eggs at Easter. I licked all around his velvety nut sac, finally lifting it and attacking his tangy puckering asshole with my ravenous tongue. My friend in the next stall had his eye to the hole and was making soft whining sounds in frustration at the opportunity he was missing.
I returned my attention to his magnificent dick, slobbering over it like a ten-cent whore, coating it with my saliva. I scooped up strand after strand of saliva and began fingering my tight asshole with my dripping fingers, working it open as wide as I could. I had to have that black monster dick inside me. I sat up and kissed him hard on the mouth and got to my feet. I turned around, facing away from him and reached back to massage his massive dick. He moved my hand away and unrolled a well-lubricated condom over his monstrous meat. Getting on my tiptoes and aiming the beautiful black head toward my tight butthole I sat back a bit, rubbing his chocolate cock up and down the crack of my ass. It was so big I knew it would rip me open but I just didn't give a fuck. I had never even seen a dick this big before and I wanted it in the worse way, reaming my ass raw.
I started centering the movements of his cock right around my asshole, until I had the head pointing right at it. I leaned back just a bit, feeling the head trying to slide into me. God, just that little bit felt like a telephone pole in my ass. "Now or never baby," I thought, threw caution and common sense to the wind, and sat my ass down as fast as I could. His dick bent hard, trying to not enter such a small opening, then straightened itself and rammed home right up my clenching ass. My black lover shoved his shorts into my mouth just as I opened it to scream in pain, and I bit down hard on the cloth wad. I closed my eyes tightly as tears ran down my face. I knew I had fucked up, that he had ripped me open. I could hardly stand and lost my balance, falling backwards onto more of his tremendous dick. Before I could fall more, I felt his strong hands on both sides of my hips. Like my weight was insignificant to him he slowly lifted me off of his dick. I felt inch after excruciating inch slide out of my tortured asshole. The head of his dick was just about out of me when he began lowering me back down on his thick rod. This time it was easier and even easier the next. Within 30 seconds I was in heaven as he raised and lowered my butt on his torrid dick. As his beautiful cock slid in and out of my ass I began clinching and unclenching by butt muscles, massaging his meat like no pussy ever could.
I could feel his dick getting ever larger in my butt and knew he was not going to hold out much longer. "Where do you want my load, sugar?, " he whispered.
"Not in a condom, in my mouth," I gasped back, as he masterfully fucked me. By this time we had moved to a standing position, me bent at the waist and he behind me slamming his dick in and out of my butt in long strokes. The feeling of being empty and full, empty and full, empty and full was like nothing I had ever felt before. This man was a masterful fucker and I loved every beautiful inch of him.
"It's time," he panted and slid his dick out of my butt. The feeling of loss in my ass was tremendous, but I turned and removed the shit-covered condom from his dick and shoved it through the hole in the wall. From the sounds I could tell my friend in the next stall was chewing on it. I was on my knees and reached for the massive dick in front of me. I stroked its fat base, gently squeezed his hot nut sac and impaled my face once again on his glorious cock. I could feel his cock jump in my hand and I pulled the head out of my mouth and rested it on my lower lip. As I massaged his balls, the head of his cock expanded, his pisshole opened and a wonderful blast of hot sperm painted the roof and back of my mouth. I swallowed and two more gorgeous shots of thick white cum erupted into my eager mouth. God, this man had it all, a cock of legendary proportions and cum that tasted like sweet nectar. After another blast from his cock, I lost my balance and fell backwards. Not missing a beat he turned to the wall and shoved his still spewing cock on through.
As he emptied the rest of his load into my friend's mouth, I scooted over behind him and began licking and kissing the cheeks of his powerful black ass. He pulled back just a bit from the wall and hunched forward. Taking the hint I spread his cheeks and attacked his beautiful asshole with my tongue. Every inch of this man tasted good. He reached back behind him and grabbing me by the hair pulled be to my feet.
"Fuck me, white boy," he rasped, pulling a condom out of his shirt pocket and thrusting it into my hand. I tore it open and rolled it over my dick. My friend in the next stall was still slobbering over his cock as I pulled his asscheeks apart and rammed my dick up his butthole. His ass was boiling hot inside as I violently slammed by dick in and out of his tight black ass. I reached under his shirt squeezing his hard muscled chest, finding his nipples and twisting them. He turned his head to the side and I attacked his face, kissing and licking him all over while I continued to fuck this gorgeous man. The beautiful contractions of his butt muscles were taking its toll on my poor dick. For the third time in less than 20 minutes I let loose with a load of hot cum. My black lover took it all up his wonderful hot ass, clenching his butt muscles to coax all of my hot load out into the condom in his ass.
I was beat, falling back onto the toilet seat, exhausted. I pulled the condom off my dick, staggered to my feet and poured my cum into my black lover's mouth. He drank it all down making smacking noises with his lips as he did. I sat down again and watched him get his cock sucked by my friend in the next stall. After a bit I started to get dressed. As I bent down to tie my shoes I couldn't help but lick my black lover's ass one more time. Man, did he taste wonderful. As I got to my feet and scooted past him toward the stall door, he reached into his pants pocket and fished out a business card, which he handed to me.
"My names Chuck," he said, beginning to pump his once again hard dick into my friend's mouth on the other side of the stall wall. "I'm in Orange County. If you ever get in the area, give me a call. You and I will do my wife if you like." I reached over and kissed him hard on the lips, "I would love to fuck you and your wife, Chuck. I'll be in touch you can rest assured."
With that I left the stall. The other guy waiting outside entered as I left. I went to the sinks and washed up as best I could, trying to get the piss and cum smells off my body. When I got back to the car my wife and boy were both sound asleep. I got in, started the engine and headed off down the road, felling like a million fucking bucks.
Why can't my code be judged by the content of its characters, and not by the color of its extension?
:)
Down with profiling!
I actually have quite a good profile but only if you catch me from my right-hand side.
3rd post!
Yes. The answer is yes. It is completely useless.
a yro article.
My first instinct was to agree with the headline, since Jose Padilla is hispanic. It would have at least made for a more interesting discussion.
Do not taunt Happy Fun Ball(TM)
It helps prevent terrorism by checking out those of suspicious national origins at airports and federal buildings. It prevents crime by allowing the police to stop people who obviously don't "belong" in a neighborhood. I would think a resident of Holland, MI would understand that better than anyone, Taco.
Maybe gprof, as an implementation might not be useful. But profiling, especially under Java, can make a world of different to an application.
Saying "profiling isn't useful" is similar to saying "having information isn't useful".
That's just dumb.
i racially profile my programs.
this sig limit is too small to put anything good h
Ulrich Drepper is a fool, he made glibc crappy, and messed up most things he had to do with. He simply should shut up and let other people do the work and the thinking.
Yeah, mod me down, but I have insight into the things Ulrich does, and he mostly does sh*t. Just my 2 cents (USD or EUR, you decide).
A monkey is doing the real work for me.
Is your workplace ADA compliant?
I am very small, utmostly microscopic.
If your goals are speed/efficiency, then profiling is a necessary step. If your goal is just to get the program done and working, then you may be able to survive without it. People shouldn't just give up on the speed/efficiency just because they figure the newest technology will handle it fine... unless you're Microsoft.
Take a look at OProfile. It's quite a nice tool, although it's not a direct replacement for gprof. From their 'About' page:
OProfile is a system-wide profiler for Linux x86 systems, capable of profiling all running code at low overhead. OProfile is released under the GNU GPL.
It consists of a kernel module and a daemon for collecting sample data, and several post-profiling tools for turning data into information.
OProfile leverages the hardware performance counters of the CPU to enable profiling of a wide variety of interesting statistics, which can also be used for basic time-spent profiling. All code is profiled: hardware and software interrupt handlers, kernel modules, the kernel, shared libraries, and applications (the only exception being the oprofile interrupt handler itself).
(For those who don't know The Turner Diaries is a pretty wild book. It was the main inspiration for Tim McVeigh in Oklahoma [besides the FBI murdering innocent people])
.30 meter, a .91 meter, an "inc. ' was 2.5 centimeters, and a "pound" .4s kilogram-approximately.)
Chapter II
September 18, 1991: These last two days have really been a
comedy of errors, and today the comedy nearly became a tragedy.
When the others were finally able to wake me tip yesterday, we put
our heads together to figure what to do. The first thing, we all
agreed, was to arm ourselves and then to find a better hideout.
Our unit-that is, the four of us-leased this apartment under a false
name nearly six months ago, just to have it available when we
needed it. (We just beat the new law which requires a landlord to
furnish the police with the social security number of every new
tenant, just like when a person opens a bank account.) Because
we've stayed away from the apartment until now, I'm sure the
political police haven't connected any of us with this address.
But it's too small for all of us to live here for any length of time,
and it doesn't offer enough privacy from the neighbors. We were
too anxious to save money when we picked this place.
Money is our main problem now. We thought to stock this place
with food, medicine, tools, spare clothing, maps-even a bicycle-but
we forgot about cash. Two days ago, when the word came that they
were starting the arrests again, we had no chance to withdraw
money from the bank; it was too early in the morning. Now our
accounts are surely frozen.
So we have only the cash that was in our pockets at the time: a
little over $70 altogether (Note to the reader: The "dollar" was the
basic monetary unit in the United States in the Old Era. In 1991,
two dollars would buy a half-kilo loaf of bread or about a quarter
of a kilo of sugar.)
And no transportation except for the bicycle. According to plan,
we had all abandoned our cars, since the police would be looking
for them. Even if we had kept a car, we would have a problem
trying to get fuel for it. Since our gasoline ration cards are
magnetically coded with our social security numbers, when we
stuck them into the computer at a filling station they would show
blocked quotas-and instantaneously tell the Feds monitoring the
central computer where we were.
Yesterday George, who is our contact with Unit 9, took the
bicycle and pedaled over to talk to them about the situation.
They're a little better off than we are, but not much. The six of
them have about $400, but they're crowded into a hole in the wall
which is even less satisfactory than ours, according to George.
They do have four automobiles and a fair-sized store of fuel,
though. Carl Smith, who is with them, made some very convincing
counterfeit license plates for everyone with a car in his unit. We
should have done the same, but it's too late now.
They offered George one car and $50 cash, which he gratefully
accepted. They didn't want to let go of any of their gasoline,
though, other than the tankful in the car they gave us.
That still left us with no money to rent another place, no} enough
gas to make the round trip to our weapons cache in Pennsylvania
and back. We didn't even have enough money to buy a week's
groceries when our food stock ran out, and that would be in about
another four days.
The network will be established in ten days, but until then we are
on our own. Furthermore, when our unit joins the network it is
expected to have already solved its supply problems and be ready
to go into action in concert with the other units.
If we had more money we could solve all our problems, including
the fuel problem. Gasoline is always available on the black market,
of course-at $10 a gallon, nearly twice what it costs at a filling
station.
We stewed over our situation until this afternoon. Then, desperate
not to waste any more time, we finally decided to go out and take
some money. Henry and I were stuck with the chore, since we
couldn't afford for George to get arrested. He's the only one who
knows the network code.
We had Katherine do a pretty good makeup job on us first. She's
into amateur theater and has the equipment and know-how to really
change a person's appearance.
My inclination was just to walk into the first liquor store we came
to, knock the manager on the head with a brick, and scoop up the
money from the cash register.
Henry wouldn't go along with that, though. He said we couldn't
use means which contradicted our ends. If we begin preying on the
public to support ourselves, we will be viewed as a gang of
common criminals, regardless of how lofty our aims are. Worse,
we will eventually begin to think of ourselves the same way.
Henry looks at everything in terms of our ideology. If something
doesn't fit, he'll have nothing to do with it.
In a way this may seem impractical, but I think maybe he's right.
Only by making our beliefs into a living faith which guides us
from day to day can we maintain the moral strength to overcome
the obstacles and hardships which lie ahead.
Anyway, he convinced me that if we are going to rob liquor
stores we have to do it in a socially conscious way. If we are going
to cave in people's heads with bricks, they must be people who
deserve it.
By comparing the liquor store listings in the Yellow Pages of the
telephone directory with a list of supporting members of the
Northern Virginia Human Relations Council which had been
filched for us by the girl we sent over there to do volunteer work
for them, we finally settled on Berman's Liquors and Wines, Saul
I. Berman, proprietor.
There were no bricks handy, so we equipped ourselves with
blackjacks consisting of good-sized bars of Ivory soap inside long,
strong ski socks. Henry also tucked a sheath knife into his belt.
We parked about a block and a half from Berman's Liquors,
around the corner. When we went in there were no customers in
the store. A Black was at the cash register, tending the store.
Henry asked him for a bottle of vodka on a high shelf behind the
counter. When he turned around I let him have it at the base of the
skull with my "Ivory special." He dropped silently to the floor and
remained motionless.
Henry calmly emptied the cash register and a cigar box under the
counter which held the larger bills. We walked out and headed for
the car We had gotten a little over $800. It had been surprisingly
easy.
Three stores down Henry suddenly stopped and pointed out the
sign on the door: "Berman's Deli." Without a moment's hesitation
he pushed open the door and walked in. Spurred on by a sudden,
reckless impulse I followed him instead of trying to stop him.
Berman himself was behind the counter, at the back. Henry lured
him out by asking the price of an item near the front of the store
which Berman couldn't see clearly from behind the counter.
As he passed me, I let him have it in the back of the head as hard
as I could. I felt the bar of soap shatter from the force of the blow.
Berman went down yelling at the top of his lungs. Then he started
crawling rapidly toward the back of the store, screaming loudly
enough to wake the dead. I was completely unnerved by the racket
and stood frozen.
Not Henry though. He leaped onto Berman's back, seized him by
the hair, and cut his throat from ear to ear in one, swift motion.
The silence lasted about one second. Then a fat, grotesque-looking
woman of about 60-probably Berman's wife -came
charging out of the back room waving a meat cleaver and emitting
an ear-piercing shriek.
Henry let fly at her with a large jar of kosher pickles and scored a
direct hit. She went down in a spray of pickles and broken glass.
Henry then cleaned out the cash register, looked for another cigar
box under the counter, found it, and scooped the bills out.
I snapped out of my trance and followed Henry out the front door
as the fat woman started shrieking again. Henry had to hold me by
the arm to keep me from running down the sidewalk.
It didn't take us but about 15 seconds to walk back to the car, but
it seemed more like 15 minutes. I was terrified. It was more than
an hour before I had stopped shaking and gotten enough of a grip
on myself to talk without stuttering. Some terrorist!
Altogether we got $1426-enough to buy groceries for the four of
us for more than two months. But one thing was decided then and
there: Henry will have to be the one to rob any more liquor stores.
I don't have the nerves for it-although I had thought I was doing all
right until Berman started yelling.
September 19: Looking back over what I've written, it's hard to
believe these things have really happened. Until the Gun Raids two
years ago, my life was about as normal as anyone's can be in these
times.
Even after I was arrested and lost my position at the laboratory, I
was still able to live pretty much like everyone else by doing
consulting work and special jobs for a couple of the electronics
firms in this area. The only thing out of the ordinary about my
lifestyle was my work for the Organization.
Now everything is chaotic and uncertain. When I think about the
future I become depressed. It's impossible to know what will
happen, but it's certain that I'll never be able to go back to the
quiet, orderly kind of life I had before.
Looks like what I'm writing is the beginning of a diary. Perhaps it
will help me to write down what's happened and what my thoughts
are each day. Maybe it will add some focus to things, some order,
and make it easier for me to keep a grip on myself and become
reconciled to this new way of life.
It's funny how all the excitement I felt the first night here is gone.
All I feel now is apprehension. Maybe the change of scenery
tomorrow will improve my outlook. Henry and I will be driving to
Pennsylvania for our guns, while George and Katherine try to find
us a more suitable place to live.
Today we made the preparations for our trip. Originally, the plan
called for us to use public transportation to the little town of
Bellefonte and then hike the last six miles into the woods to our
cache. Now that we have a car, however, we'll use that instead.
We figured we only need about five gallons of gasoline, in
addition to that already in the tank, to make the round trip. To be
on the safe side, we bought two five-gallon cans of gas from the
taxi-fleet operator in Alexandria who always bootlegs some of his
allotment.
As rationing has increased during the last few years, so has petty
corruption of every sort. I guess a lot of the large-scale graft in the
government which Watergate revealed a few years back has finally
filtered down to the man in the street. When people began realizing
that the big-shot politicians were crooked, they were more inclined
to try to cheat the System a little themselves. All the new rationing
red tape has just exacerbated the tendency-as has the growing
percentage of non-Whites in every level of the bureaucracy.
The Organization has been one of the main critics of this
corruption, but I can now see that it gives us an important
advantage. If everybody obeyed the law and did everything by the
book, it would be nearly impossible for an underground group to
exist.
Not only would we not be able to buy gasoline, but a thousand
other bureaucratic obstacles with which the System increasingly
hems the lives of our fellow citizens would be insurmountable for
us. As it is, a bribe to a local official here or a few dollars under the
counter to a clerk or secretary there will allow us to get around
many of the government regulations which would otherwise trip us
up.
The closer public morality in America approaches that of a
banana republic, the easier it will be for us to operate. Of course,
with everyone having his hand out for a bribe, we'll need plenty of
money.
Looking at it philosophically, one can't avoid the conclusion that
it is corruption, not tyranny, which leads to the overthrow of
governments. A strong and vigorous government, no matter how
oppressive, usually need not fear revolution. But a corrupt,
inefficient, decadent government-even a benevolent one-is always
ripe for revolution. The System we are fighting is both corrupt and
oppressive, and we should thank God for the corruption.
The silence about us in the newspapers is worrisome. The
Berman thing the other day wasn't connected to us, of course, and
it was given only a paragraph in today's Post. Robberies of that
sort-even where there is killing involved-are so common these
days that they merit no more attention than a traffic accident.
But the fact that the government launched a massive roundup of
known Organization members last Wednesday and that nearly all
of us, more than 2,000 persons, have managed to slip through their
fingers and drop out of sight-why isn't that in the papers? The news
media are collaborating closely with the political police, of course,
but what is their strategy against us?
There was one small Associated Press article on a back page of
yesterday's paper mentioning the arrest of nine "racists" in Chicago
and four in Los Angeles on Wednesday. The article said that all 13
who were arrested were members of the same organization-evidently
ours-but no further details were given. Curious!
Are they keeping quiet about the failure of the roundup so as not
to embarrass the government? That's not like them.
Probably, they're a little paranoid about the ease with which we
evaded the roundup. They may have fears that some substantial
portion of the public is in sympathy with us and is aiding us, and
they don't want to say anything that will give encouragement to our
sympathizers.
We must be careful that this false appearance of "business as
usual" doesn't mislead us into relaxing our vigilance. We can be
sure that the political police are in a crash program to find us. It
will be a relief when the network is established and we can once
again receive regular reports from our informants as to just what
the rascals are up to.
Meanwhile, our security rests primarily in our changed
appearances and identities. We've all changed our hair styles and
either dyed or bleached our hair. I've begun wearing new glasses
with heavy frames instead of my old frameless ones, and Katherine
has switched from her contact lenses to glasses. Henry has
undergone the most radical transformation, by shaving off his
beard and mustache. And we all have pretty convincing fake
driver's licenses, although they won't stand up if they are ever
checked against state records.
Whenever any of us has to do something like the robberies last
week, Katherine can do a quick-change job and temporarily give
him a third identity. For that she has wigs and plastic gimmicks
which fit into the nostrils and inside the mouth and change the
whole structure of a person's face-and even his voice. They're not
comfortable, but they can be tolerated for a couple of hours at a
time, just as I can do without my glasses for a while if necessary.
Tomorrow will be a long, hard day.
Chapter III
September21, 1991. Every muscle in my body aches. Yesterday
we spent 10 hours hiking, digging, and carrying loads of weapons
through the woods. This evening we moved all our supplies from
the old apartment to our new hideout.
It was a little before noon yesterday when we reached the turnoff
near Bellefonte and left the highway. We drove as close to our
cache as we could, but the old mining road we had used three years
earlier was blocked and impassable more than a mile short of the
point where we intended to park. The bank above the road
had collapsed, and it would have taken a bulldozer to clear the
way. (Note to the reader: Throughout his diaries Turner used so-called
"English units" of measurement, which were still in
common use in North America during the last years of the Old Era.
For the reader not familiar with these units, a "mile" was
1.6 kilometers, a "gallon" was 3.8 liters, a "foot" was
"yard" was
was the weight of
The consequence was that we lad nearly a two-mile hike each
way instead of less than half a mile. And it took three round trips
to get everything to the car. We brought shovels, a rope, and a
couple of large canvas mail sacks (courtesy of the U.S. Postal
Service), but, as it turned out, these tools were woefully
inadequate for the task.
Hiking from the car to the cache with our shovels on our
shoulders was actually refreshing, after the long drive up from
Washington. The day was pleasantly cool, the autumn woods were
beautiful, and the old dirt road, though heavily overgrown,
provided easy walking most of the way.
Even digging down to the top of the oil drum (actually a 50-gallon
chemical drum with a removable lid) in which we had
sealed our weapons wasn't too bad. The ground was fairly soft, and
it took us less than an hour to excavate a five-foot-deep pit and tie
our rope to the handles which had been welded to the lid of the
drum.
Then our trouble began. The two of us tugged on the rope as hard
as we could, but the drum wouldn't budge an inch. It was as if it
had been set in concrete.
Although the full drum weighed nearly 400 pounds, two of us had
been able to lower it into the pit without undue difficulty three
years ago. At that time, of course, there had been several inches of
clearance all around it. Now the earth had settled and was packed
tightly against the metal.
We gave up trying to get the drum out of the hole and decided to
open it where it was. To do that we had to dig for nearly another
hour, enlarging the hole and clearing a few inches all around the
top of the drum so we could get our hands on the locking band
which secured the lid. Even so, l had to go into the hole headfirst,
with Henry holding my legs.
Although the outside of the drum had been painted with asphalt to
prevent corrosion, the locking lever itself was thoroughly rusted,
and I broke the only screwdriver we had trying to pry it loose.
Finally, after much pounding, I was able to pry the lever out from
the drum with the end of a shovel. With the locking band loosened,
however, the lid remained as tightly in place as ever, apparently
stuck to the drum by the asphalt coating we had applied.
Working upside down in the narrow hole was difficult and
exhausting. We had no tool satisfactory for wedging under the lip
of the lid and prying it up. Finally, almost in desperation, I once
again tied the rope to one of the handles on the lid. Henry and I
gave a hard tug, and the lid popped off!
Then it was just a matter of my going headfirst into the hole
again, supporting myself with one arm on the edge of the drum,
and passing the carefully wrapped bundles of weapons up past my
body so that Henry could reach them. Some of the larger bundles-and
that included six sealed tins of ammunition
were both too heavy and too bulky for this method and had to be
hauled up by rope.
Needless to say, by the time we had the drum empty I was
completely pooped. My arms ached, my legs were unsteady, and
my clothing was drenched with perspiration. But we still had to
carry more than 300 pounds of munitions half a mile through dense
woods, uphill to the road, and then more than a mile back to the
car.
With proper pack frames to distribute the loads on our backs we
might have carried everything out in one trip. It could have been
done easily in two trips. But with only the awkward mail sacks,
which we had to carry in our arms, it took three excruciatingly
painful trips.
We had to stop every hundred yards or so and put our loads down
for a minute, and the last two trips were made in total darkness.
Anticipating a daylight operation, we hadn't even brought a
flashlight. If we don't do a better job of planning our operations in
the future, we have some rough times ahead!
On the way back to Washington we stopped at a small roadside
cafe near Hagerstown for sandwiches and coffee. There were about
a dozen people in the place, and the 11 o'clock news was just
beginning on the TV set behind the counter when we walked in. It
was a news broadcast I'll never forget.
The big story of the day was what the Organization had been up
to in Chicago. The System, it seems, had killed one of our people,
and in turn we had killed three of theirs and then engaged in a
spectacular - and successful - gunfight with the authorities. Nearly
the whole newscast was occupied in recounting these events.
We already knew from the papers that nine of our members had
been arrested in Chicago last week, and apparently they had had a
rough time in the Cook County Jail, where one of them had died. It
was impossible to be sure exactly what had happened from what
the TV announcer said, but if the System had behaved true to form
the authorities had stuck our people individually into cells full of
Blacks and then shut their eyes and ears to what ensued.
That has long been the System's extra-legal way of punishing our
people when they can't pin anything on them that will "stick" in the
courts. It's a more ghastly and dreadful punishment than anything
which ever took place in a medieval torture chamber or in the
cellars of the KGB. And they can get away with it because the
news media usually won't even admit that it happens. After all, if
you're trying to convince the public that the races are really equal,
how can you admit that it's worse to be locked in a cell full of
Black criminals than in a cell full of White ones?
Anyway, the day after our man-the newscaster said his name was
Carl Hodges, someone I've not heard of before-was killed, the
Chicago Organization fulfilled a promise they'd made more than a
year ago, in the event one of our people was ever seriously hurt in
a Chicago jail. They ambushed the Cook County sheriff outside his
home and blew his head off with a shotgun. They left a note pinned
to his body which read: "This is for Carl Hodges."
That was last Saturday night. On Sunday the System was up in
arms. The sheriff of Cook County had been a political bigwig, a
front-rank shabbos goy, and they were really raising hell.
Although they broadcast the news only to the Chicago area on
Sunday, they trotted out several pillars of the community there to
denounce the assassination and the Organization in special TV
appearances. One of the spokesmen was a "responsible
conservative," and another was the head of the Chicago Jewish
community. All of them described the Organization as a "gang of
racist bigots" and called on "all right-thinking Chicagoans" to
cooperate with the political police in apprehending the "racists"
who had killed the sheriff.
Well, early this morning the responsible conservative lost both his
legs and suffered severe internal injuries when a bomb wired to the
ignition of his car exploded. The Jewish spokesman was even less
fortunate. Someone walked up to him while he was waiting for an
elevator in the lobby of his office building, pulled a hatchet from
under his coat, cleaved the good Jew's head from crown to
shoulder blades, then disappeared in the rush-hour crowd. The
Organization immediately claimed responsibility for both acts.
After that, it really hit the fan. The governor of Illinois ordered
National Guard troops into Chicago to help local police and FBI
agents hunt for Organization members. Thousands of persons were
being stopped on Chicago streets today and asked to prove their
identity. The System's paranoia is really showing.
This afternoon three men were cornered in a small apartment
building in Cicero. The whole block was surrounded by troops,
while the trapped men shot it out with the police. TV crews were
all over the place, anxious not to miss the kill.
One of the men in the apartment apparently had a sniper's rifle,
because two Black cops more than a block away were picked off
before it was realized that Blacks were being singled out as targets
and uniformed White cops were not being shot at. This White
immunity apparently was not extended to the plainclothes political
police, however, because an FBI agent was killed by a burst of
sub-machine-gun fire from the apartment when he momentarily
exposed himself to hurl a teargas grenade through a window.
We watched breathlessly as this action was shown on the TV
screen, but the real climax came for us when the apartment was
stormed and found empty. A quick room-by-room search of the
building also failed to turn up the gunmen.
Disappointment at this outcome was evident in the TV newsman's
voice, but a man sitting at the other end of the counter from us
whistled and clapped when it was announced that the "racists" had
apparently slipped away. The waitress smiled at this, and it seemed
clear to us that, while there certainly was no unanimous approval
for the Organization's actions in Chicago, neither was there
unanimous disapproval.
Almost as if the System anticipated this reaction to the
afternoon's events, the news scene switched to Washington, where
the attorney general of the United States had called a special news
conference. The attorney general announced to the nation that the
Federal government was throwing all its police agencies into the
effort to root out the Organization. He described us as "depraved,
racist criminals" who were motivated solely by hatred and who
wanted to "undo all the progress toward true equality" which had
been made by the System in recent years.
All citizens were warned to be alert and to assist the government
in breaking up the "racist conspiracy." Anyone observing any
suspicious action, especially on the part of a stranger, was to report
it immediately to the nearest FBI office or Human Relations
Council.
And then he said something very indiscreet, which really betrayed
how worried the System is. He stated that any citizen found to be
concealing information about us or offering us any comfort or
assistance "would be dealt with severely." Those were his very
words-the sort of thing one might expect to hear in the Soviet
Union, but which would ring harshly on most American ears,
despite the best propaganda efforts of the media to justify it.
All the risks taken by our people in Chicago were more than
rewarded by provoking the attorney general into such a
psychological blunder. This incident also proves the value of
keeping the System off balance with surprise attacks. If the System
had kept its cool and thought more carefully about a response to
our Chicago actions, it not only would have avoided a blunder
which will bring us hundreds of new recruits, but it would
probably have figured a way to win much wider public support for
its fight against us.
The news program concluded with an announcement that an
hour-long "special" on the "racist conspiracy" would be broadcast
Tuesday night (i.e., tonight). We've just finished watching that
"special," and it was a real hatchet job, full of errors and outright
invention and not very convincing, we all felt. But one thing is
certain: the media blackout is over. Chicago has given the
Organization instant celebrity status, and we must certainly be the
number-one topic of conversation everywhere in the nation.
As last night's TV news ended, Henry and I choked down the last
of our meal and stumbled outside. I was filled with emotions:
excitement, elation over the success of our people in Chicago,
nervousness about being one of the targets of a nationwide
manhunt, and chagrin that none of our units in the Washington area
had shown the initiative of our Chicago units.
I was itching to do something, and the first thing that occurred to
me was to try to make some sort of contact with the fellow in the
cafe who had seemed sympathetic to us. I wanted to take some
leaflets from our car and put one under the windshield wiper of
every vehicle in the parking lot.
Henry, who always keeps a cool head, emphatically vetoed the
idea. As we sat in the car he explained that it was sheer folly to risk
calling any attention whatever to ourselves until we had completed
our present mission of safely delivering our load of weapons to our
unit. Furthermore, he reminded me, it would be a breach of
Organization discipline for a member of an underground unit to
engage in any direct recruiting activity, however minimal. That
function has been relegated to the "legal" units.
The underground units consist of members who are known to the
authorities and have been marked for arrest. Their function is to
destroy the System through direct action.
The "legal" units consist of members not presently known to the
System. (Indeed, it would be impossible to prove that most of them
are members. In this we have taken a page from the communists'
book.) Their role is to provide us with intelligence, funding, legal
defense, and other support.
Whenever an "illegal" spots a potential recruit, he is supposed to
turn the information over to a "legal," who will approach the
prospect and sound him out. The "legals" are also supposed to
handle all the low-risk propaganda activity, such as leafleting.
Strictly speaking, we should not even have had any Organization
leaflets with us.
We waited until the man who had applauded the escape of our
members in Chicago came out and got in a pickup truck. We drove
by him and noted his license number as we pulled out of the lot.
When the network is established, the information will go to the
proper person for a follow-up.
When we arrived back at the apartment, George and Katherine
were as excited as Henry and 1. They had also seen the TV
newscast. Despite the exertions of the day, I could no more sleep
than they, and we all piled back in the car, George and Katherine
sharing the back seat with part of our greasy cargo, and went to an
all-night drive-in. We could stay in the car and talk safely there
without arousing suspicion, and that's what we did-until the early-morning
hours.
One thing we decided was that we would move immediately to
new quarters George and Katherine located yesterday. The old
apartment just wasn't satisfactory. The walls were so thin that we
had to whisper to one another to avoid being overheard by our
neighbors. And I'm sure that our irregular hours had already caused
the neighbors to speculate on just what we do for a living. With the
System warning everyone to report suspicious-looking strangers, it
had become downright dangerous to us to remain in a place with so
little privacy.
The new place is much better in every way except the rent. We
have a whole building to ourselves. It is actually a cement-block
commercial building which once housed a small machine shop in a
single, garage-like room downstairs, with offices and a storeroom
upstairs.
The place has been condemned, because it lies on the right-of-way
for a new access road to the highway which has been in the
planning stages for the last four years. Like all government
projects these days, this one is also bogged down-probably
permanently. Although hundreds of thousands of men are being
paid to build new highways, none are actually being built. In the
last five years most of the roads in the country have deteriorated
badly, and, although one always sees repair crews standing around,
nothing ever seems to get fixed.
The government hasn't even gotten around to actually purchasing
the land it has condemned for the new highway, leaving the
property owners holding the bag. Legally, the owner of this
building isn't supposed to rent it, but he evidently has an
arrangement with someone in city hall. The advantage for us is that
there is no official record of the occupancy of the building- no
social security numbers for the police, no county building
inspectors or fire marshals coming around to check. George just
has to take $600-in cash-to the owner once a month.
George thinks the owner, a wrinkled old Armenian with a heavy
accent, is convinced we intend to use the place for manufacturing
illegal drugs or storing stolen goods and doesn't want to know the
details. I suppose that's good, because it means he won't be
snooping around.
The place really looks like hell on the outside. It's surrounded on
three sides by a sagging, rusty chain-link fence. The grounds are
littered with discarded water heaters, stripped-down engine blocks,
and rusting junk of every description. The concrete parking area in
front is broken and black with old crankcase oil.
There is a huge sign across the front of the building which has
come loose at one end. It says: "Welding and Machining, J.T.
Smith & Sons." Half the window panes on the ground floor are
missing, but all the ground-floor windows are boarded up on the
inside anyway.
The neighborhood is a thoroughly grubby light manufacturing
area. Next door to us is a small trucking company garage and
warehouse. Trucks are coming and going at all hours of the night,
which means the cops will not have their suspicions aroused if they
see us driving in this area at odd hours.
So, having decided to make the move, we did it today. Since there
was no electricity, water, or gas in the new place, it was my job to
solve the heating, lighting, and plumbing problems while the
others moved our things.
Restoring the water was easy, as soon as I had located the water
meter and gotten the lid off. After turning the water on I dragged
some heavy junk over the meter lid so no one from the water
company would be likely to find it, in case anyone ever came
looking.
The electric problem was a good deal more difficult. There were
still lines up from the building to a power pole, but the current had
been shut off at the meter, which was on an outside wall. I had to
carefully knock a hole through the wall behind the meter, from the
inside, and then wire jumpers across the terminals. That took me
the better part of the day.
The rest of my day was occupied in carefully covering all the
chinks in the boards over the downstairs windows and in tacking
heavy cardboard over the upstairs windows, so no ray of light can
be seen from the building at night.
We still have no heat and no kitchen facilities beyond the hot-plate
we brought over from the other place. But at least the john
works now, and our living quarters are tolerably clean, if rather
bare. We can continue sleeping on the floor in our sleeping bags
for a while, and we'll buy a couple of electric heaters and some
other amenities in the next few days.
OMG BIG PENIS ATE MY SOUP
but I suppose other people want to profile more than just Java. Bother.
While it doesn't give the exact time spent in a
given function, running 'pstack' against a
processID under Solaris will give the execution
stack trace of any threads present.
If you find that 80% of your threads are in
slow_function( someParam ) then ya better get to
work fixing it. This also has the added advantage
of not slowing down your program with profiling
code and other hooks.
Obviously this isn't great for fine-grained
profiling, or with applications with few threads,
but I've found it helpful on my larger projects.
What could be more useful is if the compiler implementor would spend as much time on the profiler than on the compiler: you would then be able to easily see faulty parts in your software and be able to determine what needs to be optimized.
Good profilers would means efficient code. Don't think profilers are useless because most implementations of them sucks.
A message from the system administrator: 'I've upped my priority. Now up yours.'
First, a little background on gprof, for those new to the *n*x world. Gprof is what's known as a profiler. Basically, it inserts code into the beginnings and ends of functions. When you run your program through gprof, it then records how much time is spent in each part of your program. The idea is that the programmer sees where most of the time is being spent, and optimizes that part of the program.
Now, as for the charges of gprof being useless, I can say that that is far from the case. True, it falls flat when dealing with multithreaded programs. But in practice, multithreaded programs are almost always interactive, and thus are primarily limited by user response times, which are many orders of magnitude longer than even the worst algorithm. In these cases, reducing the amount of input required from the user will always pay off better than any optimizations.
As an example, in our enterprise database frontend, we had a dialog that would prompt users for an administrator password when they attempted the "delete" command. We did analysis (with a commercial profiler, but it may as well have been gprof) and found that, lo and behold, the bulk of execution time was being spent waiting for the user to type in the password. So what we did was change the delete command to "eteled" ("delete" backwards), and only told the administrators the new command name. This way, we could be certain that only administrators would even attempt a deletion, and no password prompt was necessary. We have since applied the same design philosophy throughout our software, and productivity is at an all-time high.
As is usually the case, profiling can be the most important part of a project or next to useless. It all depends on how you use it. Gprof is a great tool for what it does; you just have to know how to use it properly.
Karma: Good (despite my invention of the Karma: sig)
I can't get any useful profiling information out of Microsoft Visual C++. When I compile in profiling mode, my program runs at less than 1% of normal speed, producing completely useless data. Am I doing something wrong? Should I be using 3rd party tools?
But even if you aren't doing something that is speed intensive like games, you always have tradeoffs when you choose your data structures and algorithms. Generally you first code up the easiest algorithm that you think will use an acceptable amount of memory and CPU time. Then, later, if something is too slow, you have to identify where the problem is. If could be that you chose an O(N^2) algorithm not realizing that N might be 1,000 instead of the max of 100 you were counting on, forcing you to switch to an O(NlogN) algorithm that is more complex.
Now, if it is a small application, you might have enough familiarity with the code to be able to guess where the problem is -- then you fix it and see if it is still slow. If that works, then you're set and profiling isn't necessary. But if the fix doesn't speed it up enough, then you're stuck. You have to profile it somehow.
You might try simple tricks like changing the code to loop on a suspected bit of code 100 times and see how much longer it takes. Or maybe throw in some printf's that spit out the current time at different points. Or maybe create your own profiling code that you manually call in functions you want to time. Or, you might use an actual profiler without modifications to the code. But lacking a profiler doesn't mean you can't or won't profile your code.
And even with CPU speed doubling every couple of years or so, that doesn't mean speed is no longer an issue. You can easily choose the wrong algorithm and have something take 1000s of times longer to run than the proper algorithm.
I used gprof quite much during my Master Thesis work this spring. gprof tells what functions consumes most cputime, and those functions could be optimised. Usually very small parts of the code consumes most of the cpu-time.
This program was parallellised on network level - all clients were singlethreaded. If someone has multithreaded for performance (to utilize more than one cpu) I suppose gprof will still work well on a single cpu machine with just one thread.
For programs that consumes lots of cpu time for well-defined computations it should not be hard to profile a single threaded version (a single threaded version is needed for debugging anyway).
More complex applications (for example a web browser) I imagine are more dependant on multi-threading, and should pose a larger problem.
gprof, is probably not dead - if you need it you can adapt the program...
Those of us that started programming in 1k and sub megahurts can really feel the time taken by badly coded applications. We know that forgetting what is happening on the silcon can kill how well our code will run.
However, those who started coding after ~1987 don't really have a gut feeling for it. To them the latest processor will make up for their bad coding. To a certain extent they are right. Today's advances STILL keep up with Moore's law, still make up for their lack of skill. However, when one looks at what is actually performed with all that power, one tends to question why we are paying so much, for so little.
Can you actually say that MS WordXP is much better than the non-WYSIWYG wordprocessor of yesteryear (itself a blast from the past) ?
We don't need profilers, we need coders have have that tacit knowledge of what really counts, where they should put real effort.
Unfortunately that doesn't come in a software box.
NuMega DevPartner.
Rational also used to produce something. I can't remember what it's called though. It was a companion to Purify.
Use VTune (http://www.intel.com/software/products/vtune/vtun e60/), Intel's profiler.
It does a pretty good job, and it uses performance counters.
Me: Really? Which part?
User: When I click the "report" icon
Me: Oh (tinkers with report code). Try it now.
User: It's still slow
Me: (shakes BOFH excuse 8-ball) Hrmm, must be interference from sunspots, try it again tommorrow
Today I didn't even have to use my AK; I got to say it was a good day -- Icecube
Profiling in general certainly isn't useless. I'll usually write new code primarily in a high-level, high-productivity language (e.g. Python), and if it's too slow I'll profile it and rewrite applicable parts in C. Some projects require a lower level (C) approach from the start, though those are pretty rare. Without profiling you'll spend a lot of time optimizing code that isn't a bottleneck.
Remember the words of Knuth: "Premature optimization is the root of all evil." Without profiling, you don't know what optimization is really needed and what isn't.
That said...
BEGIN RANT
I've used gprof successfully with plenty of recent code. It works perfectly fine in non-threaded code, which _should_ be the majority (99%+) of code out there. Yes, that includes big network servers (the last one I wrote just recently passed the 6 billion requests served mark without blinking). Threads are a really nasty programming rathole that should be applied in a limited way; they take much of the time and effort spent developing protected memory OSes and toss it out the window. They also tend to encourage highly synchronized executions instead of decoupled execution, which often makes things both slower and more bug-prone (locking issues are _tough_ to get right when they become more than 1-level) and slower to implement than a well-designed multiprocess solution with an appropriate I/O paradigm. Just because two popular platforms (Windows and Java) make good non-threaded programming difficult doesn't mean you should cave in.
END RANT
rage, rage against the dying of the light
Profiling, in one form or another, is ABSOLUTELY necessary. There is no other way to find out why (and where!) your code is running slowly.
Does gprof do everything we need? No. Are there better tools? Yes.
But, the bottom line is that if you don't profile your code (and unit test it, and integration test it, and...), you are not writing good code.
It's like debating if "breathing" is necessary or not.
If you want tree profiling (i.e. information about function and child performence) then Rational Quantify is a reasonable alternative to the crap profiler that comes with MSDev.
If you want a flat profiler or need to analyze the cost of specific low level operations then you MUST get Intel VTune.
I am not a number! I am a man! And don't you
It isn't just gprof that's broken by pthreads, other Linux tools fall victim as well. Core dump? Almost useless with pthreads running. Gdb? Getting better, but still a little wonky. Certain aspects of signal handling don't work as expected with pthreads.
And remember, in the immortal words of Michael Abrash, "Assume Nothing. Measure the improvements. If you don't measure, you're just guessing."
How's my programming? Call 1-800-DEV-NULL
Drepper is smoking some strange shit. Every serious programmer uses profiling.
Just because kernel and glibc wackos don't find it useful doesn't mean it isn't useful.
I regularly use profiling for any code that demands performance.
That was a very unfortunate remark of Ulrich.
--exa--
The problems that threading solves (multiple outstanding I/O's, multiple CPU utilization) can be solved using other methods. Those other methods have their evils, too, but trading off for the lesser net evil is what design and analysis is all about.
Lack of profiling tools is pretty far down on the list of tradeoffs, in my opinion; much higher up are issues of maintainability and portability, areas where threading does badly anyway.
Out in the console games development market, there's one real serious tool: a hardware profiler. Basiclly, it's a heavily modified PSX with bus analyzers tacked on so that it can snoop and tell *exactly* where the slowdowns are. Is it a cache miss? Is it the GPU hammering on things? There's none of the "this function is slow" -- it points out *why*.
D /0,,30_2252_3604,00.html was so-so at best for my use). Those apps don't do any of the fancy bus analysis, etc. Still, I'd suspect they're better than nothing.
You should not rely on profilers from the beginning of writing code, but you they're no cure-all either. A profiler can't tell you to use quicksort over a bubblesort. It just says what is slow, and it's up to the programmers to find a faster way to do things.
The most recent x86 profiler I've used was Intel's VTune (AMD's free tool at http://www.amd.com/us-en/Processors/DevelopWithAM
I know this is going to sound like flamebait, but C++ *does* make it very easy to shoot yourself in the foot with regards to performance. If you don't set up all your operators to properly take consts, if you forget to set things up, it can kill performance. If you rely on a *lot* of small functions, you can either (1) blow out the cache with a larger executable (more likely on consoles), or (2) forget to inline a few, and kill your performance with lots of *tiny* calls that probably won't show up under VTune. The slowness of various compilers makes people afraid of putting a lot of small functions in headers where they belong, as any change would force a slow, full rebuild.
I've seen C++ compilers decide to inline a 4x4 matrix copy by unrolling a loop to read/write the first 12 elements, then call the Vector4 copy constructor. Worst of all worlds. Replacing that with a memcpy was a huge win. But, the only way one would know *how* to fix that is to be able to look at the disassembly.
Nathan Mates
These days instruction-level efficiency simply isn't important outside of a few niche areas (embedded systems, games, multimedia, certain kinds of low-level systems work). To imply that knowing what's happening on the silicon is "what really counts" is nonsense. Using appropriate data structures and algorithms counts, and making correct software counts even more, but worrying about how many cycles one instruction takes versus another is a serious misdirection of effort on modern machines!
It's folks like you who are the reason people still write their SSH daemons in C, and why we live in a mixed up world where we have neither stability NOR speed!
you will find that a profiller is quite useful.
For instance, in the last year I've been developing a automatic nesting server using Linux and gprof was very important to spot the functions that were consuming more cpu time.
With gprof it was easy to notice two small functions that were responsible for 95% of the cpu usage.
As a result, I replaced that two small functions with 180 lines of optimized assembly code and I got a very good performance increase, since I was using a lot of inter-word bit shifts that the C compiler didn't handle well.
Regarding multi-threads, I come to the conclusion that 9 out of 10 times you don't really need to use threads, even in interactive programs, since there are alternative ways of acheiving the same efects.
For instance, all the X11 toolkits like Xt/Motif, Gtk+ and Qt, have the concept of work-procedures and timeout-funcions.
If you put all of your time-consuming operations inside work-procedures, you can get the same results as you would get with multi-threads, because you have an efective way of executing several taks at the same time without blocking the user interface.
Fernando Pereira
But, the bottom line is that if you don't profile your code (and unit test it, and integration test it, and...), you are not writing good code.
That's hardly true. Certainly you shouldn't waste time optimizing code until you know where the bottlenecks are. But it a lot of cases--I'd even venture to say most cases--code gets written and is fast enough. In such cases, profiling is a waste of time. Profiling is only indicated if there's a legitimate performance problem.
To a lesser extent, the same is true of unit testing and integration testing. If you're writing some code to convert one image to a GIF and you run it successfully to get the GIF, there's no reason to unit test. Even if the code has horrible bugs on some inputs, the job is done. One-off code isn't (unfortunately) uncommon. Prototype code is also very common and often you don't need to do extensive testing on it, either. Any code where the total cost of code failure is lower than the cost of QA probably doesn't need to be QA'd (which is not to say that you should spend an amount on QA equal to the failure cost; if spending $1000 on QA reduces the chance of failure by 99.999% and spending $1000000 reduces the chance of failure by 99.9999%, the $1000 expenditure suffices in all but the most demanding applications)
Sumner
rage, rage against the dying of the light
There are very few application that don't reach out across a network for information. The bottleneck is usually this network communications. Check out Performant for tools that work on the network level.
.NET, C++, C all can theoretically produce software that is just as speedy as assembly but it rarely is. People still write assembly where performance really counts (games, realtime, etc.)
There's also a continuing trend of software developers spending user's computing power to make thier jobs easier. Java, J2EE, C#,
Some people thinks that the wasted processing power is a crime. Me, I think it's just economics. It's much cheaper to pay for processing power than it is to pay for the developers to squeeze every last bit of performance out of an app.
However, there are some applications where profiling is absolutely required. Database engines, games, simulations, anything that is CPU-bound has the potential of benifiting from profiling.
You are not a beautiful or unique snowflake -- but you could be if you got off your ass.
I've solved some important real-world problems using Quantify and Purify, especially when dealing with a huge system with a lot of developers fingers in the pie. One of the programs was handling 100,000+ transacations a day, and Quantify helped shaved enough off so we didn't have to force all of our customers to upgrade their hardware.
Faced with a similar problem in Linux, I'd probably port the program to Solaris, Quantify it there, and hope the results are similar under Linux.
The next Cmdr Taco duplicate will be ready soon, but subscribers can beat the rush and see it early!
What if I run my software and it's is plenty fast? Is it still bad if I don't profile?
But processes as provided by current operating systems are too expensive to use. If I have a network server (e.g. a httpd) that has to create a process for each network request, it will never scale. In theory all that has to happen is inetd (or equivalent) fork/execs and does the necessary plumbing so that the ends of the socket are STDIN and STDOUT. Then the process just reads and writes as necessary to fulfil the request. In practice, this just doesn't work.
That's why you can't use cgi for high-volume transactions. So lets make the server a single multithreaded daemon process instead, where each request is handled by a thread. Now you can handle each request much faster, but you lose the protected address space the OS gives you in a process.
Obviously, the OS needs to change, and give use something (maybe a hybrid between processes and threads) that more closely meets applications needs. I don't see anybody making suggestions as to ways to move forward. Anybody know of research in this area?
For Java we have a really nice choice of profilers. There are basically three great products available, all of them have proved to be absolutely useful. There is JProbe, OptimizeIt and JProfiler (the 2.0 beta of JProfiler looks cool). I don't know what the problems on Linux are, but when programming Java, profiling is quite an enjoyable task.
Signature deleted by lameness filter.
mind you I have my own threads package - you need to if you want 1,000,000+ really small threads running together, with totally minimal stack space (4 bytes not the 1Mb that pthreads gives you). The only hard part was making gprof use SIGALTSTACK (which was broken in the kernel when I started). :-)
Of course this worked because from gprof's point of view I was running in one kernel thread - apart from that oprofile rocks
. . but not ever profiler is a terrorist?
Something is very confusing here - if it's already multithreaded, then the whole program isn't blocked waiting for input. And the thread that's waiting for input should be using a blocking interrupt-driven call to get the password, rather than polling for whether the user typed it or not. There's no reason for a process or thread that's blocked waiting for input to use any CPU time, so there should be no "execution time" impact. Reducing time waiting for user input would improve the overall time to complete the job, but it's not really applicable to questions of processor loading for a computationally intensive task, which is what profiling's really for.
I think this is a clever troll, and some moderator fell for it. Looking at your diary pretty much proves this point. But you had me going there for a minute, so good job in that respect.
Oh yeah, while I'm thinking about it:
3000th post! Yay me!
Your right to not believe: Americans United for Separation of Church and
minimize the use of threads whenever possible. write your code in an event driven fashion as your friendly AC suggested. the poll() system call [superior to select(), though select() works well within its fixed size filedescriptor array limits] makes this possible.
the basic mentality to switch from threads to event programming is this: anytime you're using a thread solely so that it can sit around and block on high latency events (network or disk I/O) most of its lifetime, it should not be a thread.
its acceptable to have worker threads/processes that you hand computational tasks to and they trigger an event in your event loop when they hand a result back, but don't use threads of execution to manage your state. you'll pull your hair out and still have a nonfunctional program.
i'll always choose a program that exists and works with a good user interface over one that is never released because the author(s) thought it could be faster.
listen to your profiler. everything else lies.
Ok, you got me. Now, let's apply a common sense filter to my original post.
Of course "one off, disposable code" doesn't need the same degree of "analness" applied to it as does mission critical code.
However, "fast enough" is a really bad metric to use. Yes, utility "X" is fast enough. But oh, I didn't realize it was going to be used in conjunction with utility "Y" and "Z". Now, everything is really slow. Hey, can you say Microsoft?
Fortune telling is not part of any programming job description I've ever seen.
However, "fast enough" is a really bad metric to use. Yes, utility "X" is fast enough. But oh, I didn't realize it was going to be used in conjunction with utility "Y" and "Z". Now, everything is really slow. Hey, can you say Microsoft?
Hey, I need this report on my desk every morning. It takes 3 hours to run. Let's kick it off every night at midnight.
Fast enough, even though a well-coded, well-designed implementation might take seconds to run. And mission critical. No point wasting programmer time speeding it up when we can do another project with big upside instead.
This sort of thing is not uncommon at all.
Sumner
rage, rage against the dying of the light
Um, but...I think there's a confusion of context occurring. The situation you describe happens when you're writing little chunks of one-off code to perform one task and be done with. Usually it'll be used once, or is part of a stopgap "until there's a real solution." If you're producing a product - if an entity external to your workplace is paying money for what you're producing, then you code isn't good without testing; and if you've got some spare cycles going on, profiling isn't too bad either. Something for a Malicious Coder to do when he's bored of adding bugs.
I'd even argue you have the same moral obligation to produce the same level of quality (in terms of well tested and possibly profiled code) if entities outside your workplace will use your software. Just because it was free doesn't mean it should suck.
IP is just rude.
Is there any torture so subl
First, the idea was to write in ASM to squeeze every drop of performance from the hardware.
Then, the idea was to write in a high-level language, but always be careful about performance.
Then, the idea was to develop apps quickly, then profile to optimize the important parts.
Now, screw optimization, let the user buy more hardware!
I think this attitude sucks. Even my 1.5Ghz Athlon-XP is slower running KDE 3.x (or any version of gnome for that matter) than my old 300Mhz PII was running Win98. And it doesn't do a hell of a lot of stuff that my old machine couldn't. I switched to Linux and took the performance hit because I hated Microsoft. I keep upgrading KDE (and my hardware) because the latest apps only work on the latest version. I don't expect more complex software to get faster, but I'd expect that as I upgrade my hardware, software should stay relatively the same speed. Yet, it seems as if software is getting slower more quickly than system bottlenecks (specifically RAM and hard-drive speed) can keep up. That means that the end-user experience is deteriorating, even as users pump more money into their hardware to get usable performance.
A deep unwavering belief is a sure sign you're missing something...
Isn't that what Open Source is all about?
The simple truth is that interstellar distances will not fit into the human imagination
- Douglas Adams
Um, but...I think there's a confusion of context occurring. The situation you describe happens when you're writing little chunks of one-off code to perform one task and be done with. Usually it'll be used once, or is part of a stopgap "until there's a real solution."
With testing, that's generally right. If something's going to run often, it can potentially fail a lot of times and so even a small cost of failure will be compounded to the point where QA is worthwile.
With performance, that's often not true. There are a lot of jobs that don't need anything approaching "good" performance (batch reports--I need a web usage report every morning on my desk/in my inbox--where the quick-and-dirty multipass solution that takes 3 hours to run can be scheduled at midnight, and the programmer can then do another project with big ROI instead of spending time writing a faster solution that takes only seconds to run) are one extremely common example of this (as is other batch processing). Many applications fall into that domain, many of them absolutely mission critical and responsible for millions in revenue but also not worth spending time optimizing when it could be better spent testing, adding features, or working on another project entirely.
And many (I'd say most) interactive application are fast enough from the get-go and never need optimization. Sure, there are some apps that either do a lot of computation (mp3 players, games, compilers, etc), or are run many times at once (web servers), or are too slow when first run for unknown reasons. But a lot of programs are fine from the start and profiling them is a waste.
Sumner
rage, rage against the dying of the light
And for getting even more useful information out, try Prospect. It works with OProfile - there was a talk about it at this year's Ottawa Linux Symposium, which you can find in the conference proceedings (gzipped PDF).
Do you even know anything about perl? -- AC Replying to Tom Christiansen post.
But what happens whe the program files overnight, and the poor user comes in in the morning to find that he doesn't have enough time to run the program again before the deadline? I bet at that piont, he'd appreciate the well-coded, well-designed version...
A deep unwavering belief is a sure sign you're missing something...
But what happens whe the program files overnight, and the poor user comes in in the morning to find that he doesn't have enough time to run the program again before the deadline?
Then you profile and optimize, because it's not "fast enough" any more.
Is that hard to understand?
Sumner
rage, rage against the dying of the light
I agree that profiling isn't always necessary, and that sometimes profiling and optimization won't reap any advantage, but I think the range between not necessary and useless is wide, and the advantage from profiling in that range is subtle but existant.
Additionally, profiling can serve other purposes. It's been suggested that, under a unit testing regime, a coder new to a project can serve as a "Malicious Coder," whose job it is to add bugs to code to catch out situations the unit tests miss. The advantage is that this can improve the testing as well as bringing up a new team member quickly. Profiling/optimization tasks can serve a similar purpose. By giving a direction to code investigation, it speeds the acquisition of familiarity with the code.
IP is just rude.
Is there any torture so subl
If you don't take a cursory run with a profiler on it, you'll never know the real cost of speeding it up.
It's worth a quick overview of the profile, to determine how long it would take to optimize said report.
I talk from painful experience - a job I once worked at ran overnight DB jobs on their Oracle database. Nobody bothered checking for efficacy of their SQL until the jobs that had accrued grew to take more than 8 hours in total, and were still running when users came in for the morning.
Then, with a scant four days of programmer, the jobs got pared back to three hours, AND some bugs got fixed. If they'd done that a few months earlier, we would have avoided 4 months of pain and anguish from users coming in, trying to use the system, and screaming bloody murder because it still wasn't available for them at 7:30 AM.
How *NIX grognards always complain about multi-threading, but don't find signals (and their nasty interrupt-driven nature) to be the least bit unsettling!
A deep unwavering belief is a sure sign you're missing something...
Now, compute intensive code tends not to spend a lot of time in system calls, so it isn't clear that it matters whether a profiler counts time spent in system calls. I kind of prefer if it doesn't because it doesn't clutter up the profile with I/O delays (which are usually unavoidable).
If you want to find out where your code is spending time in system calls, you can use "strace -c".
There are also gcov-like tools that can be used for profiling via code insertion (as opposed to statistical profiling like gprof), although I'm not sure whether PC hardware has the necessary timer support.
Overall, the answer is: yes, profiling still matters for programs that push the limits of the machine. But fewer programs do. I think most people would be a lot better off not programming in C or C++ at all and not worrying about performance. Too much worry about "efficiency" often results in code that is not only buggy but also quite inefficient: tricks that are fine for optimizing a few inner loops wreak havoc with performance when applied throughout a program. Too much tuning of low-level stuff also causes people to miss opportunities for better data structure and program logic. This is actually an endemic problem in the industry that affects almost all big C/C++ software systems. Desktop software, major servers, and even major parts of the kernel should simply not be written in C/C++ anymore.
The thing with profiling and optimization is to know when to stop, and few people know that. So, maybe the best thing to say is: "no, profiling doesn't matter anymore". That will keep most people out of trouble, and the few that still need to profile will figure it out themselves.
If you don't take a cursory run with a profiler on it, you'll never know the real cost of speeding it up.
Right. It's obviously a cost/benefit tradeoff. If you start the report at midnight and need it at 8:00 in the morning, then if it takes 15 minutes to run you probably don't even want to think about profiling. If it takes 7 hours, it's still fast enough for now but you may want to concern yourself with whether it'll always be fast enough. What's the cutoff? 1 hour? 4 hours? Depends on how crucial the report is and what other projects are on your plate at the moment.
Obviously "performance problem" is tough to quantify in general, but I still contend that you should normally only profile if there is a potential performance problem (or if you have idle resources, etc). Otherwise, go do some QA. Work on a new project. Clean up the nasty hack you wrote late at night to get it going. Write some documentation. Whatever.
Sumner
rage, rage against the dying of the light
_Native_ _x86_ multithreading is useless and harmful.
1) It heavily decreases number of processes - a very tight resource in Linux
2) It makes programs cumbersome and hard to debug
3) In x86 architecture in Linux it was not a good idea to make threads implemenation via context switches for thread switches - in x86 it's a very costly operation.
But it's only rant. Same as MIME this flawed technology is already used a lot and it's no way to turn it back.
(why mime? mime is a stupid thing - a dirty hack created from not wanting to rewrite old 7-bit protocol from scratch).
What could be more useful is if the compiler implementor would spend as much time on the profiler than on the compiler: you would then be able to easily see faulty parts in your software and be able to determine what needs to be optimized.
Better yet, if an architecture has a static branch predictor that encodes "mostly taken" or "mostly not taken", the compiler could emit profile code that measures how fast a particular variant runs and then take that into account for the next optimization pass.
Will I retire or break 10K?
I program a lot in c++, and I particularly like to use the STL. Thus, my programs often have a lot of inlined functions in them. I have found gprof to be much less useful when profiling such programs.
When a function is inlined, gprof does not account for that functions time. Nor should it be exepcted to, since optimizations may reorder the code so much that it is not feasable to attribute a particular assembly instruction to a particular function. I have tried recompiling my programs with -fno-inline to expose the names of the inlined functions, but this changes the program performance so much in some cases that I am hesititant to draw any conclusions about a program from such a profile. Short of abandoning inlining (and interprocedural optimizations, which poses the same sort of problem), does anyone have suggestions on how to profile such programs?
From a QA perspective, multi-threading has the same problems as global variables -- too much coupling, too much exposed data. If you are running a multiprocessor system and the program can be parallelized, then multithreading might be worth the trouble. But for most applications it causes more trouble than its worth.
Five bucks says that this server is slashdot'ed within the hour, so you may have more success with the less descriptive SourceForge project page, indicates that the project is not dead, as the homepage says.
I discovered this program when I was optimizing some code I wrote to multiply sparse matrices. By the time I had gotten it 100x faster than the initial code, gprof had lost all semblance of granularity and was giving me obviously bogus results. The problem is that such things as cache performance (i.e. optimizing for cache hits) were now heavily affecting the profile and gprof could not figure such things out. FunctionCheck works much better than gprof and actually generates accurate profile information under high-stress situations.
From the homepage (all grammatical errors theirs):
"I created FunctionCheck because the well known profiler gprof have some limitations:
- it is not possible to change the profile data file name
- multi-threads / multi-processes is not supported
- time spend in non-profiled functions is discarded
- you can't control the way profile is made
- memory profile is not managed
For all these limitations, and by the fact that I discovered a new gcc feature called -finstrument-functions, I decided to write my own profiler.My approach is simple: I add (small) treatments at each enter and exit of all the functions of the profiled program. It allows me to compute many information:
- the current call-stack
- the time at each action, to compute elapsed times in functions
- process PID / thread ID, to manage multi-threads / multi-processes
- number of calls to functions
...
With these information, I can generate profile data files (for each thread / process), which describes all the statistics (at function level) for the program execution."Try it out and please contribute some source code.
and thus are primarily limited by user response times, which are many orders of magnitude longer than even the worst algorithm.
User response time is many times faster then the time it takes for a function to return that's stuck in an infinet loop.
(appended to the end of comments you post)
Here's a call-graph profiler I wrote a while ago. It's rough and ready, but it does the trick, and works with both multiple threads and shared libraries.
e /
x86 Linux only. README.txt included, if it breaks keep all the pieces.
http://homepages.ihug.co.nz/~suckfish/scgprofil
The output is a series of records vaguely like the gprof call graph:
calling_functions
function_name
called_functions
The numbers are numbers of samples.
Ok, I agree that non-threaded code can be easier to understand than threaded code, and can usually run faster.
However, I'd like to hear what you'd do in a situation like this: You have a network server that has to respond to incoming packets within something like 50 ms (it's for a multiplayer action game). The server also needs to keep track of player information in a database, so it uses something like the mysql C client library. But then it has to block on a mysql_query or mysql_insert, because that library doesn't provide any way to do things asynchronously (this maybe have changed with newer versions; I looked at mysql a few years ago). Or what about DNS resolution? Or any other blocking event other than plain IO through an fd?
One solution might be to fork off a process doing the mysql, and have it communicate with the parent through pipes/sockets. But you have to invent a small, one-time protocol for each of these you do. And did I mention this has to run on Windows too, whose IPC sucks?
Well, if gcj's JVMPI becomes fully usable, maybe we could us a tool like JProfiler for natively compiled Java code. That would be great.
You rock.
But he didn't say that... He said that programmers should know where to invest the effort, and take an interest in creating efficient code. That means, first and foremost, exactly what you just said: you have to be smart about your DS&As, aware of what you're writing and not pointlessly lazy when coding. It doesn't mean, and wasn't claimed to mean, that you have to micro-optimise everything at the assembler level.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
I couldn't agree more. Sadly, the fact that almost everyone replying to your post thinks it is advocating premature optimisation at the level of assembly-level tweaks makes your point all too well.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Don't use threads.
The problem you are complaining about profiling having is that it can't profile threaded programs. Don't write threaded programs, and the problem is solved.
Frankly, I've always considered threading useful for only a few situations:
o When you have an SMP system, and you need to scale your applicaiton to multiple CPUs so that you can throw hardware at the problem instead of solving it the right way
o When you have programmers who can't write finite state automata, because they don't understand computer science, and should really be asking "Would you like fries with that?" somewhere, instead of cranking out code
o When your OS doesn't support async I/O, and you need to interleave your I/O in order to achieve better virtual concurrency
Other than those situations, threads don't make a lot of sense: you have all this extra context switching overhead, and you have all sorts of other problems -- like an iniability to reasonably profile the code with a statistical profiler.
OK... Whew! Boy do I feel better! 8-).
Statistically examining the PC, unless it's done on a per thread basis, is just a waste of time in threaded programs.
If you want to solve the profiling problem for threaded programs, then you need to go to non-statistical profiling. This requires compiler support. The compiler needs to call a profile_enter and profile_exit for each function, with the thread ID as one of the arguments. THis lets you create an arc-list per thread ID, and seperately deal with the profiling, as if you has written the threads as seperate programs. It also catches out inter-thread stalls.
-- Terry
Bah yourself. Who's this Knuth guy, and what the hell does he know about efficient programming, anyway?
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Read again what he said : _minimize_ thread use doesn't mean _don't_ use thread. Obviously there are case when you can't avoid using threads (like the one you described), but most of the time, it's possible to poll on resources (poll() on UNIX, select() on BSD, WaitForMultipleObjects() on Win32), and it should be done so to save on system overhead.
Why are these mutually exclusive? There's efficient and there's optimised, and one is a much easier subset of the other.
He's not claiming that everyone should hand-optimise from the word go. He's saying programmers should have a basic knowledge of their craft. It doesn't take much extra effort to use an efficient sorting algorithm or store data in a fast look-up structure, rather than writing a naff, hand-crafted shuffle sort and using arrays for everything whether they're appropriate or not. And yet, through ignorance or plain laziness, most programmers in most languages take the latter approach. (If you've never seen any of the source code for big name applications/OSes, trust me, it's scary.)
Similarly, it is just careless to pass large structures by value unnecessarily in a language that has reference semantics. You have to know the basics of what is efficient use of your tools of choice if you want to write good code, and the old Moore's Law excuse is just a cover for laziness and failure to do the requisite amount of homework.
Note that, very importantly, none of these things requires more than a small effort. They certainly don't compromise maintainability, bug count or any other relevant metrics, and a competent programmer (if you can find one) will take these things in his stride, and still be faster than the others.
Interesting... We have just acquired a new P4/2.2GHz with 512MB RAM and running WinXP as a development machine at work. You know what? It's way, way slower than the 1.4GHz P4 running 2000 we already had. And that in turn is way slower than the 1GHz P3 running NT4. This is not subjective, it is based on obvious, objective measures. For example, my new machine (the fastest of the above) sometimes takes 3-4 minutes to act on an OK'd dialog in Control Panel. The NT4 box reacts instantly when you configure the equivalent options. Something is wrong at this point, and I'm betting it's a combination of code bloat and feature creep.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
gprof is maybe not the most impressive tool to use, but it's quite useful. At a IA64 course at university [German, sorry] we used gprof to identify the bottlenecks in the c-code of the xvid-codec. Then we assembler-optimized like mad and got quite a nice speed-up.
Result can be found in our wiki:
Pre-OptimizationPost-Optimization
Without gprof we would have been lost... our IA64 wiki
comments about the poor implementation of
threads in Linux. Other writers suggest
avoiding threads, if possible. Note
that Java is nothing but threads. Any
Java program is running 4-6 threads (depending
on the JRE) right out of the box.
Where I work, we have had
severe problems getting Java programs to
work correctly on Linux. The IBM Java
support team has shared our frustration.
Maybe IBM's new thread implementation is
needed, just to get Linux, Java (and
thread users in general) working correctly
in an enterprise environment. After that
is working, then we can see about improving
other areas like performance.
See http://www.BitWagon.com/tsprof/tsprof.html for info on a process profiler that uses hardware performance counters (with no recompile and no relink) and gives both interactive and text output in tree and flat modes.
I suppose I'm already following that advice: I'm using a combined thread/main-loop design in the current server. There are a fixed, small, number of threads for things that are time-criticial or might block, and also a loop running in the main thread that calls a bunch of registered functions every once in a while, for low-priority tasks.
The problem is this: once you start using threads, even a few, you have to start protecting your data structures with mutexes and probably use other synchronization methods as well. If your code already has mutexes around shared structures, then there's little harm in adding a few extra threads. The big benefit I can see from minimizing threading is to get it down to a single thread, so that you can eliminate all of the synchronization overhead.
Huh? You'd better hope your boss ain't reading this.
And your attempt at keeping folks from running commands you think they shouldn't is pretty damn feeble. How do you decide someone has typed in your 'eteled' command? Maybe a strncasecmp() or similar? So if I do a "strings -a" on your executable I'd see a weird string pop out like "eteled"? And maybe I'd wonder why it was stuck in with all the strings called "select" and "update"?
OOOH, you so smart.
Has anyone ever tried to run xxgdb and gdb against a threaded program?
Has anyone tried calling fork1() from within one thread of a multithreaded process? One third of your threads shouldn't disappear, one third shouldn't wind up hung, and one third shouldn't get brain-damaging memory corruption.
I've actually reached the point of telling folks that come to me with MT requirements for Linux processes to pay the money and run Solaris. It's cheaper than paying me to get Linux threads working correctly.
Here you go: fma()
Saying profiling is useless is equivalent to saying that algorithmic complexity doesn't have to be studied. This is absurd. ;)
If for example your profiler says your function foo() is executed 100 times with a data of size 10 and 10000 times with a data of size 20, you have a serious algorithmic complexity problem. If some of them can (and should) be handled before hand, a profiler is very useful to handle those that weren't.
Algorithmic complexity is independant of computer language and of CPU speed, therefore profilers will always be useful as long as algorithmic is used by computer languages, so for quite some time still
I wouldnt say that gprof is useless... threading, however, comes very close to it.
Threading is useful in the instance where you have an application that needs to scale with SMP and which you cannot, for whatever reason, fork. But the accompanying pain of being forced to pay extremely close attention and mutex lock the code all over makes it not worth it for most situations.
Use fork. Use other IPC methods if necessary. But dont thread or you'll spend an order of magnitude more time debugging.
That depends on your point of view. Personally, I write lots of technical documents, where every other word (ish) isn't in the dictionary. That "better interface" makes my screen unreadable, since it's littered with red. On top of that, I usually spell correctly in the first place, and look words up in a dictionary as I go along if I'm not sure. Spell checkers rarely have to correct genuine mistakes in my documents. So personally, I'd much rather see that feature done away with and have the performance back, rather than waiting for Word to catch up as I type, as I had to ten years ago. If it's useful for others, by all means have it as an option, but don't call it "better" in a blanket statement.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Thanks for that information. I'm about to upgrade my trusty PII/350 running Win98 to a nice, new top-of-the-range custom-built beastie. Well, it's been four years, and it was my birthday last week. :-)
I'd been considering installing Linux as an alternative to MS stuff, since I now object enough to the nature of Microsoft's attitudes to make the effort to switch. In the light of your information, I think I'll just install Win2K instead.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
I agree with the rant, though. I have developed and maintained some significant sized threaded applications, and I loathe to do it again unless necessary.
> What about databases like Oracle, MS SQL Server,
> and so on? They're internally multithreaded,
Oracle, at least the last time I played with it
was NOT multithreaded by default. There was a
multithreaded config option, but Oracle recommended
that you did not use it.
I remember reading somewhere recently that computers use about 17 percent of power from the electricity supply grid. The latest PCs need 300W supplies, which helps neither the environment nor availability and cost during times of peak load. It's even worse because of the extra demand for AC, not to mention fan noise. Code that lots of people run should avoid excess bloat and inefficiency not just for improving end-user experience as measured by things such as response times.
Hmm, it depends on how you pay for hardware (cpu-cycles for ex.), now doesn't it?
Take IBM's scheme for Mainframes where you pay for what you use... Here I can certainly see long term gain / reduction of costs / benefit for a company optimizing a batch job taking 3 hours into running in a few seconds. Often these bottle necks don't cost astronomic sums, but "letting a ksh script loop in OMVS" certainly will.
In a society that believes in nothing, fear becomes the only agenda ~ Bill Durodié
C is rather common, and it has the "floating multiply-add" functions fma, fmaf and fmal.