Todd M. Bezenek

I sponsor the Unicode equals sign1 as a representation of all things which are and should be considered equal. Please treat your fellow humans the way you wish to be treated in return.

Given the opportunity to live where rights are earned or where rights are purchased, I prefer to live where they are earned, which means I must and I try to live up to the equals sign, rather than only support it financially.

Donation of Cloud Computing Resources

I am encouraging cloud computing providers to donate their unused compute capabilities to charity. I recommend donating to Network Contagion Research Institute (NCRI) which works to reduce deception, manipulation, and hate on the Internet.

Another option is the Stanford Internet Observatory (SIO), part of the Stanford Cyber Policy Center, which works to build the necessary tools—access to data, information processing resources, and talent—to study the negative impact of emerging information technologies and how they can be abused or used to abuse individuals or groups.

Of particular interst moving forward will be SOI's open Journal of Online Trust and Safety.

If you are Interested in Hiring Me

I am currently working as a consultant at Intel in the Data Center (Cloud Infrastructure) Group. Since it is a consultant position of limited duration, I am interested in hearing about future opportunities. Please take a look at my LinkedIn profile or ask for a copy of my resume via email at bezenek(at) if you are interested.

I do SW/HW co-design in computer architecture and software systems. I interface with people who do RTL, but I do not do it myself other than small tweaks when needed. I'm the computer architecture and software expert who straddles the HW/SW line and knows as much as possible about the software side and how it interacts with the hardware architecture.

I also do software and systems performance tuning for scale, speed, and energy use.

Finally, I can do software development. I can work in embedded systems, large, scalable systems, and systems with workload-specific hardware. My background in both computer sciences and electrical engineering make me a versatile employee for building software systems.

Here are Some Highlights from My Work Experience:

  • I did some of the ground-breaking work in the analysis of program phase behavior and its application to computer architecture, including processor design uses for improved performance while saving power at the same time.
  • I enjoy the challenge of working in a cross-team setting. My broad background enhances my ability to contribute in that setting.
  • I have an excellent experimental background and the ability to avoid faulty experiments and invalid conclusions. I have worked with several simulation technologies used to explore new architectural designs.
  • I have worked with some of the best software/hardware/systems research people in the world, and I consider them my peers.
  • I enjoy augmenting the abilities of those around me and vice-versa.
  • Bonus: I have the ability to learn not only from marketing material, but from the technical research literature, so I learn the best solutions, not those most highly recommended by the people selling them.

Again, if you would like a copy of my resume, please send email to bezenek(at) I also read my email at bezenek(at), but not nearly as often.

Why I left Wisconsin Without a Ph.D.

I left the University of Wisconsin Computer Sciences Department in December of 2001. While there, I studied computer architecture as a post-graduate for six years, and was active in research for four years. I left with everything but the dissertation when the person with whom I was working on a paper did not complete their side of the agreement.

My Research: Program Phase Behavior and Its Use to Impove Performance and Decrease Power Consumption

In 1998-99, my research focus was understanding program behavior and how knowledge of it can be applied in making architectural decisions. In particular, I studied workload phase behavior. One day I ate lunch with David Wood. He was interested in what I was doing, but pointed out I would have to show program phases existed before I could talk about them. I already had that. If you look at the work done by Brad Calder, et al., the figure at the bottom of his phase analysis website shows the phases in GCC. The phases reading from the left from 0 to 10 billion instructions executed are:
  • Parsing of the source to tokenize the source is shown. (in white)
  • Builing the compiler's interal representation of the code. (in cyan)
  • Common subexpression elimination (CSE). (in blue)
  • Loop unrolling. (the segment between the two blue bands)
  • A repeat of CSE to catch opportunities exposed by loop unrolling. (in blue)
Note: I do not remember what the red band after CSE is, nor did I analyse the rest of the bands to the right of 10 billion instructions. At the time, the important thing was to be sure it made sense, and understanding what was happening at every point was not important.
The website is a color rendition of the content in the 2002 ISCA paper publised in IEEE Micro by invitation. Introducing program phase behavior is not publishable on its own. An application must be included. My application was configuring a reconfigurable bimode branch predictor using the output of the Phase Detection and Prediction Unit, or PDPU. The PDPU detects phases using a signature generated by the XOR of the last N call targets stored in a ring buffer. Reproducability is guaranteed by XORin each branch target when it enters the ring buffer and then XORing it again when the target is removed as the head of the buffer comes back around.

Looking at my 1999 diagram of the reconfigurable hybrid bimode predictor shown on the right, the choice of which of the two branch predictors to use is determined by the accuracy of the branch prediction results the last time the identified phase was executed. In this way, the bimodal predictor is used when we have highly predictable behavior for that prediction method, i.e., looping, and the bimode predictor is used when we do not.

The PDPU and reconfigurable predictor above are similar to what was published in a technical report at the University of Colorado in 2004.

When the bimodal predictor is being used, we turn off the bimode predictor. This saves power and eliminates destruction of the bimode predictor state by the part of the program which is easily predictable by the bimodal predictor. The resulting reconfigurable, hybrid predictor is both more accurate, i.e., performs better and uses less power than a standard bimode predictor.

I did not publish this work because my Ph.D. advisor was interested in pursuing something else, which did not get published because the paper was not written. My responsibility was building the experiemental infrastructure and gathering the results. The paper was being written by others and was not completed in a timely manner.

Please note all good ideas are going to be discovered if it is time. When I did not publish this work, Brad Calder and his students did the same thing because it was time for this to be done. My only disappointment is that something similar to the PDPU did not gather enough momentum for it to become part of production designs in the way power management did.

Gene Amdahl's Thesis and the WISC Computer

You may be interested in reading Gene Amdahl's Ph.D. Thesis, University of Wisconsin, October 11, 1951. It is titled The Logical Design of an Intermediate Speed Digital Computer.2 The design described in the thesis was constructed at UW from 1952 to 1955. The floating-point unit was added in 1957. The computer—aptly named WISC, or Wisconsin Integrally Synchronized Computer—provided digital computing capabilities for both instructional and research use. WISC was retired in 1962, due to the cost of preventive maintenance and the recent arrival of a new IBM 1620.

I discovered Gene's thesis in one of the subfloors of the main library at Wisconsin when I was looking for something else. I called Gene and started the process resulting in Gene's being able to meet with the Wisconsin CS Alumni group in Silicon Valley a few years later.

I later had a meeting with my Ph.D. advisor at the time and the Dead of the College of Engineering at Wisconsin about moving the one implementation of the WISC computer to the new main engineering building. That effort did not succeed, and the WISC computer is in the archive of the Computer History Museum where it cannot be seen. There is an old car in the engineering building where the WISC likely would have stood.

Collected Quotes

    Here are some quotes I collected over the years:

  • This came from Vern Bennett's eulogy during my grandmother, Ethel Eshom's funeral. She taught grade school for 37 years, before retiring in 1974.
  • She looked for something that each student did well, instead of looking for faults.

    —Dr. Vern Bennett, former Director of the Fargo, North Dakota Public School System.

  • This Calvin Coolidge quote comes from Professor Charles Dyer's3 .plan file. When I was his teaching assistant I noticed it. President Coolidge was not an academic, but I agree with his ideas.
  • Nothing in the world can take the place of persistence. Talent will not; nothing is more common than unsuccessful men with talent. Genius will not; un-rewarded genius is almost a proverb. Education will not; the world is full of educated derelicts. Persistence and determination alone are omnipotent.

    —Calvin Coolidge, 30th President of the United States of America.

  • I forgot to record where I found this one.
  • Many of life's failures are people who did not realize how close they were to success when they gave up.

    —Thomas A. Edison, American Inventor.

  • This was quoted by multiple people at Jim Gray's rememberance ceremony at UC Berkeley on May 31, 2008, several months after his disappearance. I remember how cool it was when someone asked the audience who had been on Jim's boat, and about two-thirds of the about 500 (guessing—it could have been more) people there raised their hands. If someone knows how many people were there, send me an email and I'll put in the correct number.
  • A people hire A people, B people hire C people.

    —Jim Gray, database researcher and 1998 Turing Award winner.

  • This is from Bjarne Stroustrup's book, The C++ Programming Language, 4ed.
  • You don't have to know every detail of C++ to write good programs.

    —Bjarne Stroustrup, inventor of C++.


1 The spelling of equals is as specified by the Unicode Consortium.

2 Please follow the University of Wisconsin copyright guidelines for electronic materials when using this document. Also, there is a better copy of the thesis somewhere on the Internet. I did my copy with the Wisconsin Computer Sciences Department photocopier using a faculty member's borrowed (with permission) access code. The other one looks much better.

3 I found out about the September 11, 2001 attack on the World Trade Center when I walked into Chuck's class to be introduced as his TA. He told me what happened. I looked at the class and said, "This is a joke, right?" Chuck was nice enough to take care of the final project presentations for me, and Jim Smith was good enough to ensure my 899 Virtual Machines course partner was not penalized because I was unvailable when I had to return to North Dakota to bury my grandmother who raised me along with her daughter, my mother, who passed away about two years earlier.