just in time debugging

For more than a decade, academics and technology executives have been frowning at the widening gender gap in computer science. Everyone has a theory, but no one has managed to attract many more women.

Now, some computer science researchers say one solution may lie in the design of software itself ― even programs regular people use every day.

Laura Beckwith, a new computer science Ph.D. from Oregon State University, and her adviser, Margaret Burnett, specialize in studying the way people use computers to solve everyday problems ― like adding formulas to spreadsheets, animation to Web sites and styles to word processing documents.

A couple of years ago, they stumbled upon an intriguing tidbit: Men, it seemed, were more likely than women to use advanced software features, specifically ones that help users find and fix errors. Programmers call this "debugging," and it's a crucial step in building programs that work.

Beckwith decided to investigate why women and men might interact so differently with the same software. She pored over 30 years' worth of books and academic papers from psychologists, education researchers, economists, computer scientists and others about gender differences in problem solving and computer use.

One theory grabbed her attention: High confidence correlates with success. Both men's and women's confidence in their ability to do a challenging task affects their approach and the outcome. And most studies indicated that women ― even ones who study computer science ― have less confidence than men in their computer skills.

So Beckwith wondered, could that be one of the culprits? Are women less confident than men when it comes to software debugging? Are women less willing than men to try using these advanced features?

Beckwith tackled these and other questions in her dissertation, with guidance from Burnett and Susan Wiedenbeck of Drexel University.

She started by asking a group of women and men, in a questionnaire, whether they believed they could find and fix errors in spreadsheets filled with formulas.

Then, she sat them down in front of a computer with two spreadsheets. One tracked students' grades, and another calculated employees' paychecks.

Beckwith buried five errors in each one without telling the participants. She gave them a time limit and asked them to test all the formulas and fix any bugs.

The program included a debugging feature that helped the users spot miscalculations by the formulas underlying the spreadsheet and other errors. When they clicked on a number that seemed wrong ― a grade point average that looked too low, given the student's test scores, for example ― cells in the spreadsheet grid that contained the possible source of the error changed color. If the participants were sure a formula or value was correct, they could check it off.

In this experiment, the key to success was using the debugging feature. Both men and women who used it were better at finding and fixing the bugs.

The level of confidence expressed by the participants in the questionnaire about debugging, however, played a much different role for the genders.

For men, it didn't really matter whether they believed they could complete the task. Some men with low confidence used the debugging tools, and some with high confidence didn't.

But for the women, only those who believed they could do the task successfully used the automated debugging tools. The women with lower confidence in the task relied instead on what they knew ― editing formulas one by one ― and ended up introducing more bugs than when they started.

Beckwith was faced with a conundrum. From questionnaires handed out after the experiment, she knew women understood how the debugging tools were supposed to work, so it seemed their confidence level was lower than it deserved to be. She also knew that one way to boost confidence is through successful experiences. But it was this low confidence that was keeping women from using the debugging tool and having a successful experience.

As a computer scientist, Beckwith wasn't interested in changing women's confidence levels. She was interested in whether changing the software could help women over this hurdle.

So she explored whether a gentler presentation of the debugging tool, one that seemed to require less confidence, would appeal to women.

In the first study, the debugging tool let users mark values "right" or "wrong." To mark something as wrong, participants had to right-click with the mouse.

In later studies, Beckwith added two more choices: "seems right maybe" and "seems wrong maybe." The "maybe" buttons worked just like the more certain-seeming ones, but used softer colors to indicate possible errors. She also changed the program so that no one needed to right-click the mouse, something less-experienced computer users are reluctant to do.

Beckwith tested the new feature during several other experiments. When she tallied up the numbers, she found that in some experiments, women used some form of the debugging feature almost as often as men did. In others, they used the debugging tools even more than men did.

Although these experiments homed in on a tiny aspect of a computer user's life ― debugging spreadsheets ― the implications could be quite large.

Burnett, the Oregon State professor, estimates that 55 U.S. million computer users of both genders are essentially writing programs even if they don't know it ― such as when they set up filters on their e-mail.

While software used by the country's 3 million professional programmers include ample debugging tools to ensure their code works as it should, the increasingly complex software used by everyday PC users doesn't.

Research like Beckwith's may help ensure that when the industry starts adding new features for those everyday computer users, differences between men and women aren't left out of the equation.

What's more, making complex everyday software more accessible to women could help get more of them interested in computer science, Beckwith and Burnett believe.

As it is, the percentage of bachelor's degrees in computer science awarded to women fell from 37 percent in 1985 to just 22 percent in 2005, according to the National Center for Education Statistics, even as women made gains in other science and math-based fields.

Most gender-gap theories today have more to do with computer science's image as a haven for solitary male geeks. Industry groups and high-tech companies tend to suggest remedies like mentoring girls, and changing computer science education to better show how the field is connected to everyday topics thought to be of more interest to girls, like media, sharing and communicating.

While Beckwith and Burnett acknowledge that there are numerous social and developmental factors behind the gender gap, they say their research adds a new dimension to the debate.

"The first time you as a girl sit down at a computer to do some real problem solving," Burnett said, "and the software you're using isn't a good fit for your learning style, your problem solving style, how likely are you to be to say, `I'm going to grow up and be a computer scientist?'"

Julie Jacko, a professor at the Georgia Institute of Technology and president of the Association for Computing Machinery's group on human-computer interaction, said research like Beckwith's could end up changing how young women feel about computers.

"We know from our colleagues in psychology and sociology that there are gender differences that can be very important to take into account in human-computer interaction and software design," Jacko said. "Projects like this can help us have a better impact, even at younger ages, where I believe interventions need to happen."

The research may be early, but the software industry is paying attention. Beckwith's first job isn't in academia ― it's at Microsoft Corp.

There, she'll put her research experience to work helping the team that designs software for programmers. That group has never given much thought to the user's gender, said Susan Todd, Beckwith's boss-to-be.

"In the past, since we concentrate so much on developers ― and as you know, there are not a lot of women developers ― we haven't really gone in that direction," Todd said. "I think it's going to be something that will be really quite interesting for us to look at."

But don't expect "Excel for Women" any time soon. Beckwith and Burnett point out that there are male computer users whose learning styles and problem-solving skills have more in common with the typical female user, and vice versa.

As Burnett said, "We're not advocating a pink version of blue version of software, because that wouldn't fit anybody."

How important is multithreading in application development? Well, if you ask me, it is the wave of the future. I certainly write about multithreading often enough. Unfortunately, not all applications lend themselves very well to being multithreaded. There is a blog post on MSDN called "SMP a 'dead end.'" I think that the author makes a lot of excellent points, not the least of which is that all too many applications still need one big core to work effectively. However, where the author gets it wrong is in failing to see where the CPU market is headed and that the days of Moore's law applying to individual cores is over for the time being.

I have been working on a very nifty little application for an article I am writing for about a month's worth of weekends now. It does some image editing. Unfortunately, the editing it performs is rather CPU intensive. But the CPU crunch show a rather intriguing pattern. As you can see in this Task Manager screenshot (Figure 1), one of my cores (this is a Core 2 Duo system) is cranking pretty hard. The other core is spinning but not so hard. The difference between the two is that the hard working core (the one on the right) is running my application. The "lazy" core is me doing the rest of my work on the PC, as well as Visual Studio handling the overhead of my application running within it (I am still debugging). For example, the two big spikes on the "lazy core" are two times where UAC kicked in (I was moving items on the Program menu).






Figure 1 (Click image for full size)

What can I do here? I have a few choices. My first option is to leave the situation as it currently stands. Sure, the application is taking 10+ hours to run through a relatively lightweight operation, but it is rock solid on reliability, and the RAM usage is insanely stable, which reduces a tons of page file hits. My next choice is to try multithreading some portion of the work. As you can see, I have one core working hard, but one of them is not doing a thing to help me out here; there is a lot of untapped power in my hardware. The system is still extremely responsive, and I am not seeing any slowdown. Looking at the graph (and the process list), my application is hovering around 48% or so of CPU, which is nearly 100% of the core that it is on. Popping off a second thread would therefore make the system really slow (since I would be taking 100% on both cores) but may allow me to finish the task in half the time. That is a tough trade off to consider.

Is there a middle road? Can I multithread this smartly? And what about the cost of context switching?

I think there is a middle road in this case. Looking at the workload, there is no one particular portion of the workflow that could be performed asynchronously. And even if there was, none of the operations are long enough for the cost of context switching to be offset. Now that being said, the overall operations are performed in near total isolation of one another, and while they work with a common point of memory, that access is fairly quick and is only a small portion of the functionality. In other words, it is a low contention area. So having identified only one potential contention area (and being a rare case of a block occurring), we have found our middle road. What I am going to try is to split the loop up, following my general rule on the number of threads: single thread CPU usage * number of logical cores. In other words, if it takes 50% of one logical core to run the processing thread, you do not want more than four threads running on a system with two logical cores. That puts your workload at 100% of all cores. Now that being said, I often decrement that number by 1, just to ensure that the base OS and other applications are not completely squeezed. After all, does your customer care that your application is as efficient as possible if it effectively renders their PC useless while it is running? Probably not.

In this case, however, I am going to try something different. Usually I will split the loop evenly and have each loop do its work in perfect parallel. This time, I am going to have one thread marked as a special "stutter thread" (I am making up words here ― I am not sure if there is a proper term for this). The work will not be evenly divided; the "stutter thread" will have only half of its "fair share" of work to do and the other threads will have the other half evenly divided amongst themselves. In exchange for having less work to do, the "stutter thread" will only "work" 50% of the time. The other 50% of the time it will remain idle, freeing a touch more CPU for the OS and other applications. I will most likely use a semaphore tied to another thread (say, thread 0 signals the "stutter thread" on every other iteration). I could also use a monitor (thread 0 locks the enters the monitor on every other iteration, and the "stutter thread" also tries entering the monitor). I think either approach would be viable.

I will let you know in a few weeks how this goes (I am going out of town this weekend, so I will not be working on it).

National Instruments has updated two add-ons to its graphical toolsuite aimed at helping non-computer programmers such as engineers and scientists create design, control, and test applications. The two LabView 8.5 add-on updates bring support for uClinux on ADI's Blackfin DSPs (digital signal processors), and on TI's ColdFire MCUs (microcontroller units).

LabView was originally launched for Apple's Macintosh in 1986, a heady time during which many if not most of the dominant paradigms in desktop computing software user interfaces were being established. After all, the first computer with a mouse -- the Apple Macintosh -- had shipped just two years before.

LabView was among the first development tools to use a graphical development model. Its interface lets users graphically model their application by assembling function block diagrams. Behind the scenes, the diagrams are converted to NI's own proprietary "G" language, and subsequently compiled.



LabView's graphical user interface
(Click to enlarge)

G is said to be highly portable among OSes and processor architectures. In addition to its new support for uClinux on Blackfin and ColdFire, it supports OSes that include Linux, Mac OS, and Windows, and processor architectures that include ARM7, TI c6000, XScale, and PowerPC. With an optional FPGA software add-on, it also supports the use of FPGAs (field-programmable gate arrays), on which users can implement hardware logic devices such as custom peripherals.

LabView 8.5's new support for uClinux on Analog Devices Inc. (ADI's) Blackfin DSPs requires an add-on called "Embedded Module for ADI Blackfin Processors 2.5." The add-on appears to work in tandem with ADI's own VisualDSP++ 5.0 product, and the combination is said to enable engineers to create sophisticated systems such as medical devices and sub-sea monitoring systems.

ColdFire support, meanwhile, requires the optional LabVIEW Microprocessor 2.5 SDK. The newest release of this add-on also brings background TCP/IP debugging, said to enable developers to debug applications without compromising real-time performance.