ECS 50 Blog, Fall 2012

Monday, Dec. 10, 10:38 a.m.

If you wish to have me pre-review your report submitted by today's noon deadline, it must be a full report. That also implies that it must successsfully "compile" when I run pdflatex.

Sunday, Dec. 9, 11:12 p.m.

As mentioned in class, I'm out of town most of this week (Boston). E-mail access will be good in the evenings (EST), but spotty during the day.

Saturday, Dec. 8, 6:06 p.m.

Concerning the MIPS and JVM architectures: My knowledge of both of them is basically limited to what is in the handout. If you do not hand-compile, make sure to do a bit of Web research regarding any "new" instructions you encounter. Indeed, such research to me is one of the best benefits of doing the project.

Saturday, Dec. 8, 1:14 p.m.

In working on the MIPS/JVM question in the Project, please keep in mind the spirit of that question: The goal is to get an introduction to two non-Intel architectures, especially in an optimization context.

In that light, consider my comment in class that you may wish to use the cross-compiling capability of gcc to produce MIPS code, and to use gcj to produce JVM code. (Note that there isn't that much advantage to using gcj, since javac and javap give you the same or better capabilities.)

The point is this: If you "hand-compile" the C code, explain why you believe your choice of MIPS/JVM machine code is efficient, relative to other alternatives. If you have a compiler do the compilation, explain why what it produces from the C code is or is not efficient.

Friday, Dec. 7, 10:37 p.m.

In submitting your Project .tar file, please do not make subdirectories. When my grading script unpacks your .tar file, it will expect to see all your Project files in the same directory from which the script invokes the tar command.

Friday, Dec. 7, 9:13 p.m.

One student is unclear on the Project, and in case others are too, here is a summary. The Project has 3 goals to it:

  1. Explore how gcc optimization produces better, i.e. faster executing, machine code (Problem I).
  2. Get an introduction to two non-Intel architectures (Problem I).
  3. Give some thought to whether it is desirable to write mixed C/assembly code, e.g. by inlining as in Matt's presentation, as a means of attaining more speed (Problem II).

These 3 aspects of the Project are basically independent of each other. Indeed, I could have made them 3 separate problems, rather than combining the first two goals into one problem as I did. The first two goals are not connected, other than the fact that they both ask you to use PrimesThreads.c as the example. And the first and third goals are not connected either, as they are dealing with different types of optimizations.

Thursday, Dec. 6, 5:47 p.m.

To MCN: All my e-mail to you is rejected.

Thursday, Dec. 6, 5:33 p.m.

If on Quiz 6, Wednesday section, you answered 2 instead of $2, let me know. You should get full credit.

Wednesday, Dec. 5, 8:24 p.m.

There seems to be some confusion on Problem II of the Project.

The term optimization here does NOT refer to things like the -O1 options in GCC. That doesn't affect portability, as one can simply recompile the source code on a new architecture or OS.

Instead, this is a reference to writing part of a program in assembly language, even though most of it is in C/C++. Remember, Matt gave a lecture on that topic. This kind of code is NOT portable.

Also, concerning Problem I:

In C/C++, a statement is basically anything that ends with a semicolon, such as

x = y + 2;

With if, for and so on, one can have compound statements.

For this problem, a simple (noncompound) statement is enough, but compound statements are fine too. Just make sure your three examples have sufficient variety to them.

Wednesday, Dec. 5, 6:39 p.m.

I've had a couple of people ask me how to generate 32-bit code on a 64-bit machine, because some assembly instructions have problems, e.g.

push %eax

Since on a 64-bit platform the EAX register is only a half-word (the full register is RAX) and a stack consists of full words, this is a problem.

The GCC option -m32 generates 32-bit code, IF one's GCC installation is configured with this option. Ours on CSIF is not, and the one on your own machine might not be either.

On our Group Quiz tomorrow, I will avoid including problems that have such a dependency, so you don't have to worry about it. Just make sure that the introductory assembly program in Chapter 3 (sum a four-element array) works, especially in GDB.

Wednesday, Dec. 5, 5:11 p.m.

On p.228, the code is missing .global _start. It should read

.text
hi:  .string "ABC\n"
.globl _start
_start:

      # write "ABC\n" to the screen
      movl $4, %eax     # the write() system call, number 4 obtained
                        # from /usr/include/asm/unistd.h
      movl $1, %ebx     # 1 = file handle for stdout
      movl $hi, %ecx    # write from where
      movl $4, %edx     # write how many bytes
      int $0x80         # system call

      # call exit()
      movl $1, %eax     # exit() is system call number 1
      int $0x80         # system call
Wednesday, Dec. 5, 1:53 p.m.

This is a renewal of the request in my blog entry of Nov. 20, 8:53 p.m.

Wednesday, Dec. 5, 11:10 a.m.

I just e-mailed everyone all their Quiz records. Please check them.

Tuesday, Dec. 4, 8:23 p.m.

Forgot to add: In order to fit the x array on the stack (needed as a local), I needed to shorten it.

Tuesday, Dec. 4, 2:44 p.m.

When I first discussed threads in class a few weeks ago, I believe I put an "asterisk" next to my statement that one "must" use global variables. If one wishes to work very hard, one can technically avoid globals though still having them in spirit. The question about Java threads this morning prompted me to elaborate on this point now.

Consider the prime numbers program in our book. I've placed a globals-free version here. Let's see how it works.

The main point is that I moved the things that were global in the original version to local variables within main(). I then passed these variables to worker() in a struct container.

I would argue that these variables are still global in spirit, as they are still shared by all the threads, but that of course could be debated. What cannot be debated is that the code became much, more complex. Creating a new struct, in which to package all the variables that used to be global, really added complexity to the code. For example, note these lines in main().

   for (i = 0; i < nthreads; i++)  {
      // this call says create a thread, record its ID in the array
      // id, and get the thread started executing the function worker(), 
      // passing the argument i to that function
      thrdargs[i].n = n;  // lock pointer
      thrdargs[i].threadnum = i;
      thrdargs[i].nbptr = &nextbase;
      thrdargs[i].primearray = prime;
      thrdargs[i].lockptr = &nextbaselock;
      pthread_create(&id[i],NULL,worker,&thrdargs[i]);
   }

and these lines in worker():

void *worker(struct threadargs *ta) 
{  int lim,base,
       work = 0;  // amount of work done by this thread
   int n = ta->n;
   int tn = ta->threadnum;
   int *primes = ta->primearray;
   pthread_mutex_t *nblckptr = ta->lockptr;
   // no need to check multipliers bigger than sqrt(n)
   lim = sqrt(n);
   do  {
      // get next sieve multiplier, avoiding duplication across threads
      // lock the lock
      pthread_mutex_lock(nblckptr);
      base = *(ta->nbptr);
      *(ta->nbptr) += 2;

What used to be

      base = nextbase; 

for instance, is now

      base = *(ta->nbptr);

This added code complexity makes the code much harder to write, debug and read--and all for no benefit in my opinion.

Again, see the Intel blog that advocates using globals in threads apps.

Monday, Dec. 3, 11:10 a.m.

I've added some clarifications to Problem II on the Project.

Sunday, Dec. 2, 2:12 p.m.

If you had a late Quiz submission, you will still be able to use the 1.0 grade point bonus after December 3.

Sunday, Dec. 2, 2:12 p.m.

Please note that I have not graded the late Quizzes yet. I hope to do so in the next two days, and will then send out grade summaries for everyone.

Saturday, Dec. 1, 8:50 a.m.

Details on the MOOCs talk:

The Online Revolution: Education for Everyone
Thursday, December 6
3:30 - 4:30 pm
Kemper Hall 1003

Abstract: We are at the cusp of a major transformation in higher education. In the past year, we have seen the advent of MOOCs - massively open online classes (MOOCs) - top-quality courses from the best universities offered for free. These courses exploit technology to provide a real course experience to students, including video content, interactive exercises with meaningful feedback, using both auto-grading and peer-grading, and rich peer-to-peer interaction around the course materials. At Coursera, as of November 2012, we offer 207 courses from our 33 university partners, and over 1.9 million students from 196 countries. The courses start from bridge/gateway courses all the way through graduate courses, and span a range of topics including computer science, business, medicine, science, humanities, social sciences, and more. In this talk, I'll report on this far-reaching experiment in education, and why we believe this model can provide both an improved classroom experience for our on-campus students, via a flipped classroom model as well as a meaningful learning experience for the millions of students around the world who would otherwise never have access to education of this quality.

***

Daphne Koller is a Professor of Computer Science at Stanford University and the co-founder of Coursera, a social entrepreneurship company that works with top universities to make the best education freely accessible to everyone. In her research life, Koller works in the area of machine learning. She has received the Presidential Early Career Award for Scientists and Engineers, the MacArthur Foundation Fellowship, the ACM/Infosys award, and membership in the National Academy of Engineering. She is an award winning teacher, who pioneered many of the ideas that underlie the Coursera user experience. She received her BSc and MSc from the Hebrew University of Jerusalem, and her PhD from Stanford in 1994.

Friday, Nov. 30, 8:40 a.m.

You will recall that Sebastian Thrun, founder of one of the two major MOOCs (Massive Open Online Courses) companies, Udacity, was to give a talk on MOOCs earlier this quarter, but had to cancel for medical reasons. No word yet on his rescheduling, but his competitor Daphne Koller will be here on December 6. Here is the announcement from Mrak Hall:

Colleagues: I wanted to make sure you knew that Daphne Koller, co-founder of Coursera--a major provider of Massive Open Online Courses (MOOCs), will be visiting the UC Davis campus on Thursday, December 6 to deliver a lecture on this exciting new development in online learning. Please join us to learn more about the MOOC movement and please pass this on to your chairs and indeed all those who feel may find this of interest.

Though for some reason students are not mentioned, presumably you do fall into the category of "may find this of interest," and I urge you to attend. Koller, like Thrun and like Koller's Coursera cofounder Andrew Ng, is a famous computer scientist at Stanford. It's always good to see how famous people think about things. So, I strongly encourage you to attend, whether you find the MOOCs concept appealing or not.

Personally, as I've said earlier in this blog (e.g. see my October 31 posts), I am not a fan of MOOCs. I believe they result in shallow courses (go to Udacity and Coursera and check out some in subjects you 've already taken and decide for yourself), and their sole purpose is to make money for MOOC firms and save money for university administrators in ways that lower standards. I find the claims to altruism ("Now someone in the Gobi Desert can learn quantum mechanics!") to be disingenuous; if altruism were the motivation, why are Coursera and Udacity formed as for-profit companies? And for that matter, if online instruction is so effective, why do Thrun and Koller have to come to our campus in person? Surely an interactive online Webinar presentation of "this exciting new development" should be enough, right?

Thursday, Nov. 29, 10:46 p.m.

As noted, for the Group Quiz you'll need at least one laptop with gcc (and as, which should come with gcc), gdb and pthreads. If no one in your Group has a laptop with Linux installed (or, Macs should have those apps), there are several options you have:

The first two are described in my tutorial on Linux installation. Note in particular the USB key method, which should be very easy, following the instructions at UNetbootin. It should also be easy to install a virtual machine, using the CSIF instructions. This last method has the advantage that gcc etc. will already be there, as opposed to your having to install separately.

Needless to say, these are imperative, whatever approach you take:

Make sure nothing goes wrong in the Group Quiz! This really will require teamwork, even before the Quiz.

Thursday, Nov. 29, 8:11 p.m.

I've noted before that most UC CS graduates end up working for firms with either fully or partly Linux environments. When that came up today, I noted that Google is a Linux shop, and mentioned a funny incident recounted in a book by a former high-level employee of Google. A student looked it up, and found that the book is I'm Feeling Lucky, by Douglas Edwards. Edwards, a marketing expert, writes that he was frustrated when he needed to get help on Windows issues. When he asked who in the firm knew Windows well, the reply was "No one." "Really?", he replied incredulously.

Google developed their own in-house version of version of Ubuntu, called Goobuntu. There is an interesting article about it here.

Thursday, Nov. 29, 5:22 p.m.

No discussion section next week.

Tuesday, Nov. 27, 5:44 p.m.

I've fixed a typo and the wording in Section 11.1.5.2 in the revised version of our book.

Tuesday, Nov. 27, 2:24 p.m.

As stated in class today, the number of page faults (and cache misses) is an absolutely crucial aspect of performance-oriented computing. This is reflected, for instance, in the performance monitoring software that comes in major OSs.

For example, you may be aware of the Linux time command, which as the name implies is used to measure run time of a program when you execute it. What you may not realize is that it also reports the number of page faults, as that can be a major slowdown factor.

Here I ran our primes program:

% time primes 10000000 2
209 values of base done
236 values of base done
the number of primes found was 664579
0.888u 0.068s 0:00.64 146.8%    0+0k 696+0io 7pf+0w

There were 7 page faults. Since each one involves going to disk, a mechanical operation, this is of big concern. (Subsequent runs had fewer faults, though.)

Here's an example from the Windows world.

Tuesday, Nov. 27, 2:17 p.m.

Note that in a pthreads app, one could try to maximize speed by writing the worker function in assembly language, keeping the rest in C.

An example is the prime number-counting program in our book. I've set up two files, Prime2.c and Worker.s to do this. I haven't done anything to optimze Worker.s (actually, for convenience, I just ran the original code through gcc -S), but I could.

Tuesday, Nov. 27, 11:14 a.m.

When I stated earlier that today would be a hard deadline for Homework 4, I merely meant that I would not be postponing it any further. The rules in the Syllabus concerning late Homework, e.g. your 2 late days, still apply.

Tuesday, Nov. 27, 8:42 a.m.

In the scaled-down version, you write only the worker function in assembly language, and the rest in C. Communicate addresses of locks etc. via globals.

Tuesday, Nov. 27, 8:42 a.m.

Hopefully the vast majority of you have already completed or are close to completing Homework 4. For those groups that haven't, I will be announcing a scaled-down version that you can do for most of the credit later today. Also, if you haven't read the Syllabus regarding late policy, do so now.

Sunday, Nov. 25, 8:00 p.m.

Regarding that 7:09 p.m. entry below, the twin goals of this assignment are (a) to give you some experience with pthreads and (b) to solidify your understanding of subroutines and stacks. The assignment is not meant to imply that pthreads code is often written in assembly language.

Sunday, Nov. 25, 7:09 p.m.

Matt will hold very generous office hours this week: Tuesday 10:30 a.m.-4:00 p.m. in Kemper 67. No office hours on Wednesday.

Note, though, that you can help yourself by making sure you are really scrutinizing your stack contents.

Friday, Nov. 23, 2:40 p.m.

In other words, assume that in the worst case WiFi will be down or ridiculously slow during part or all of the duration of the Group Quiz. Do NOT count on using gcc etc. on CSIF; you will be using these things on your OWN machine.

Friday, Nov. 23, 1:10 p.m.

That 12:10 posting means what it says. You MUST have the capability of doing any of our work on your machine. This is because WiFi is not reliable.

For an example of why this is necessary, note that at the end of the Group Quiz (our usual 1:20 lecture duration), you will use handin to submit your files (.c and/or .s). If the WiFi system is overloaded, you will not be able to do this, and will have to give me your files on an USB memory stick. (Which I'll bring to the Quiz.)

So, you'll be doing your development, testing and debugging on your own laptop.

Friday, Nov. 23, 12:10 p.m.

More on our Group Quiz, Dec. 6: As noted, each Group must have at least one laptop computer. (Let me know if this is a problem.) But note carefully that that computer must be capable of doing the work of our course. In particular, make sure it has gcc, gdb and pthreads installed. Note that this needs to be "real" pthreads, not for example Cygwin (which lacks barrier calls).

Friday, Nov. 23, 11:00 a.m.

Keep in mind that when you write an assembly language subroutine that is called from C, you must make sure that upon exit from the subroutine, the register values in use before the call are still intact.

Wednesday, Nov. 21, 4:37 p.m.

The barrier example I posted last night is to be considered an official part of the course, eligible for Test questions. Make sure to make a hard copy, and bring it to tests.

Wednesday, Nov. 21, 11:00 a.m.

Please recall that during our Group Quiz, each Group must have at least one laptop computer. I recommend testing the WiFi in our classroom beforehand.

Wednesday, Nov. 21, 10:56 a.m.

Near the end of the quarter, I will e-mail you my full records of your Test grades. The TA will e-mail you the full records of your Homework grades.

Wednesday, Nov. 21, 11:53 a.m.

Next week's Quizzes will cover the material through Section 11.1.5.4, top of p.222.

Tuesday, Nov. 20, 8:53 p.m.

If you send me e-mail concerning your Quiz, make sure you state whether you are in the Tuesday or Wednesday section, as the records are separate.

Tuesday, Nov. 20, 8:53 p.m.

I've placed an example of barrier use here.

Tuesday, Nov. 20, 8:15 p.m.

Special Offer, Part II: I am making the same offer as I did in the Saturday, Oct. 27, 9:53 a.m. blog entry, this time for Quizzes 4, 5 and 6. (In the case of ECS 50, Quiz 6 is next week.) If you notify me by Monday, December 3, I will raise your grade on your choice of Quiz (4-6) by 1.0 grade point.

Tuesday, Nov. 20, 2:30 p.m.

If you submit your Homework by the original due date, i.e. 11:59 p.m. this evening, and if you do not resubmit later, you will receive Extra Credit.

Tuesday, Nov. 20, 11:16 a.m.

If you are having trouble with seg faults in pthread_join() it is likely that you have misspecified the arguments. Inspect carefully with a debugging tool.

As a stopgap measure (not good for permanent use), you could use a loop in ucdsort() to wait for the threads to finish. In C it would look like this in our primes example:

int ndone = 0;  // global
...
pthread_mutex_t endlock = PTHREAD_MUTEX_INITIALIZER;
...
if (base <= lim) {
   ...
} else {
   pthread_mutex_lock(&endlock);
   ndone++;
   pthread_mutex_unlock(&endlock);
   return;
} while (1);
...
// inside main()
...
// wait for all done
while (ndone < nthreads) ;

// report results
nprimes = 1;
for (i = 3; i <= n; i++)
...
Tuesday, Nov. 20, 10:36 a.m.

As discussed in class today, I have moved the due date for Homework 4 back one week. Needless to say, this is a hard deadline.

Monday, Nov. 19, 10:49 p.m.

I've mentioned before that I recommend (in general) writing code in "baby steps." Don't write the full-blown version at first; start with a scaled-down version, say finding only the overall min and max rather than doing the sort.

Monday, Nov. 19, 10:40 p.m.

Follow up to my message earlier today: Your function ucdsort() should look roughly like this:

initialize, e.g. allocate memory for pthreads variables
for i = 1,...,nth
   call pthread_create() to run worker()
for i = 1,...,nth
   call pthread_join()

The function worker() should look like this:

I am worker i
find my min, my max
update overall min, overall max
barrier
determine my chunk range
cull my array elements
write my chunk size to i-th element in global size array
barrier
copy my chunk to its proper place within x
call qsort() on my chunk in x
Monday, Nov. 19, 10:52 a.m.

You should only call pthread_create() ONCE for each thread. If say nth is 8, then this function should only be called 8 times in the entire execution of ucdsort(). Calling this function exacts a heavy toll in delay.

Sunday, Nov. 18, 9:16 p.m.

Specs are specs. Although I am always open to suggestions for slight variants, the basic specs have been chosen for reasons. So, stick to the specs. If you wish to has a small variant, make sure to clear it with me before you start coding.

Sunday, Nov. 18, 2:16 p.m.

For this coming week only, Matt will hold office hours on Monday instead of Wednesday. Specifically, he'll be available during 11:30-1 and 2-4. That overlaps with my 2-3 hour, but that's fine because I believe lots of people will have questions about Homework 4, so he and I can share the consultation load.

Sunday, Nov. 18, 9:00 a.m.

If you've done considerable work on the assignemnt, which is hopefully the case, you will have discovered that waste of some form is unavoidable in many programs.

A prime example is that in our current assignment, you need to set up space for the array chunks, and really there are only two options. One would be to set up n words of memory for each chunk, with a total of n * nth words; this is wasteful of memory. On the other hand, you could have each thread make a preliminary pass through x to determine how many elements it needs to cull out, and then set up that many words of memory for its chunk; this is wasteful of execution time. It's up to you to choose on which aspect to concede waste.

Saturday, Nov. 17, 4:41 p.m.

Concerning the level of difficulty of the current assignemnt:

Saturday, Nov. 17, 12:51 p.m.

As mentioned in the Syllabus and in class, the formula given in the Syllabus for determining course grades is only a lower bound. You are guaranteed that you will get at least that high a grade, but I may use qualitative factors to raise that grade. This occurs fairly often, in something like, I'd guess, 20% of the grades.

Here are examples of factors I may use in raising a grade above what the formula gives:

By the way, I often use the same information when I write letters of recommendation.

Saturday, Nov. 17, 12:31 p.m.

IF YOU HAVE TURNED IN ANY QUIZ FILES LATE, OR ANTICIPATE DOING SO, PLEASE NOTE THE FOLLOWING CAREFULLY.

I definitely understand that you may occasionally forget to turn in your electronic Quiz file on time. You will continue to get full credit for late submissions, no penalty imposed. BUT I NEED YOUR HELP. The following will save a lot of work (much more than you may realize). Please note that this will be REQUIRED.

If you turned in any of the Quizzes late AND you have not received a grade from me, you must submit the file via handin in a special *late directory. For instance, in the case of Quiz 3, ECS 50, Tuesday section, you would submit to the 50quiz3tueslate directory. For ECS 132, same Quiz, you would submit to 132quiz3late directory.

Again, this is REQUIRED, for all Quizzes to date, and for those remaining. I really appreciate your cooperation.

Near the end of the quarter, I will be e-mailing each of you all Test records I have for you.

Saturday, Nov. 17, 10:56 a.m.

I've mentioned before that in our programming assignemnts, the actual coding is not typically difficult, but the challenge lies in figuring out how to make use of the machine itself--the hardware and the system software.

The current assignment really embodies that spirit. A case in point is that someone asked me this morning how much space to allocate for the pthread_t type. I replied that this assignment requires you to do some detective work. I also noted that I had mentioned a couple of times in class that it would be educational to browse through the #include files, both for pthreads and in general. There are also various other ways to figure out the size of the pthread_t type. The point is that you have to be resourceful.

Keep in mind that THIS IS NOT "SINK OR SWIM." Matt and I are always ready to give you hints if you reach an impasse on any aspect of an assignment. Hopefully, it usually doesn't come to that point, because in a 3-4 person group, there will be at least one person who says, "Hey, maybe we could do it this way..."

Anyway, to emphasize the fact that there are several "Hmm, how do we do this?" aspects to this assignment, I'm moving back the due date by one day, to Tuesday.

Friday, Nov. 16, 2:10 p.m.

If you have turned in any Quiz files late, or anticipate doing so, please watch this space for an important announcement later today.

Thursday, Nov. 15, 4:18 p.m.

If you turned in your Quiz late, please note what I said before: It may take quite a while before I get to the "stragglers."

I will not grade Quiz 5 (regular, not stragglers) until at least Saturday. So, if you sent me a late file for that Quiz, please submit it NOW via handin, and send me e-mail notifying me of this, so I don't have to go through hand-grading your Quiz.

Thursday, Nov. 15, 1:50 p.m.

Today we mentioned the fact that threads are naturally suited for GUI programming, because with many GUIs one doesn't know which of two or more input devices will send something next.

Say that at some time the user of the GUI has a choice of either mouse or keyboard input. The program can't simply call scanf(), because the user might input on the mouse instead of the keyboard. Once scanf() is called, it would wait forever, thus not giving us a chance to read from the mouse.

So, instead we set up two threads, one for the keyboard and one for the mouse. One may wait forever, but that won't matter, since the other thread will eventually get a turn and the input will be done.

What I had forgotten is that we actually have an example of this in our book, in Sec. 9.4.5.2. Here we have multiple keyboards, no mice, but it's the same principle.

Thursday, Nov. 15, 10:54 a.m.

Two people asked me after class about a double major between CS and Statistics, so I thought I'd write some points on this here on the blog:

Wednesday, Nov. 14, 3:49 p.m.

OK, project specs ready, in our Hwk directory. Note the word "noon" and the phrase "no late submissions."

Wednesday, Nov. 14, 3:15 p.m.

Oops, jumped the gun. Wait a few minutes.

Wednesday, Nov. 14, 2:38 p.m.

Your final hwk/final exam is now on the Web.

Monday, Nov. 12, 8:38 p.m.

The "supercomputer" coprocessor that Intel has been promising for several years now has finally been released. 60 cores! (And 4-way hyperthreading for each core.) Initial retail price over $2600, so not quite ready for home use yet, but certainly usable by university departments, small businesses (e.g. financial forecasting) etc.

Sunday, Nov. 11, 2:22 p.m.

TO AVOID DISRUPTING THE GRADING PROGRAM (and resulting penalty), please review and keep in mind the blog post of Thursday, Oct. 18, 11:27 p.m.

Sunday, Nov. 11, 2:03 p.m.

Please review the blog entry of Sunday, Oct. 28, 11:56 a.m., and WRITE DOWN THE INFORMATION in your book or other handy place. You will need this on Tests.

Sunday, Nov. 11, 9:43 a.m.

For your Homework, please note that there is material on debugging threaded programs in Section 9.4.5.3.

Sunday, Nov. 11, 9:35 a.m.

I've just made a major revision of Chapter 10, Multicore Systems, here. As you know, you are NOT responsible for reading the revision, but you may find it helpful, as much has been clarified. I would recommend in particular the material on "what can go wrong" if one forgets to use locks, starting around p.202, and the material on the Intel LOCK prefix, around p.206.

Saturday, Nov. 10, 9:35 p.m.

You are required to use pthreads to create the threads, but may use assembly language directly to do things like locks if you wish.

Saturday, Nov. 10, 8:45 p.m.

I've fixed a couple of typos in the Homework, and made one point more explicit.

Saturday, Nov. 10, 11:00 a.m.

There is an extraneous Section 10.1 in our book, on NVIDIA. Ignore it.

Saturday, Nov. 10, 9:18 a.m.

I've added a number of clarifications to Homework 4, including an example.

Friday, Nov. 9, 11:48 p.m.

Homework 4 is now on the Web.

Friday, Nov. 9, 9:33 a.m.

EXTREMELY IMPORTANT INFORMATION concerning the remainder of the quarter. Make sure all your Group members are aware of this.

Thursday, Nov. 8, 11:42 p.m.

No discussion section, Nov. 21.

Thursday, Nov. 8, 11:40 p.m.

Forgot to mention today: An especially good Final Project paper often leads to a higher course grade than the formula would give. In other words, I give Extra Credit for really good papers.

Wednesday, Nov. 8, 8:40 p.m.

If any of you know the student in our class with initials EF and student number 998499273, please tell this student to contact me as soon as possible.

Sunday, Nov. 4, 10:40 p.m.

Stack underflow means attempting a pop on an empty stack.

Sunday, Nov. 4, 6:40 p.m.

Assume that no data item in the current Homework will ever be -1.

Sunday, Nov. 4, 4:07 p.m.

I had a typo in the definition of the links in the current Homework, fixed now.

Saturday, Nov. 3, 1:51 p.m.

Please note again that the material Matt presented in discussion section this past week is considered to be official course material, and will almost certainly show up on Tests.

Matt's presentation, possibly including some new material, will be available soon on our course Web page. Please note carefully that he will use LATEX  to prepare this file. Since you will be using this typesetting system to write up your final project report, Matt's .tex source file will be a good example from which can learn the LATEX  system.

LATEX  is the standard typesetting system in the academic engineering and science community, due to its outstanding math capabilities. It is also the tool used to typeset math on Wikipedia.

See my quick tutorial, or the many others on the Web, such as this tutorial at Stanford and this one at Berkeley.

Saturday, Nov. 3, 1:25 p.m.

I just e-mailed out the grades for the people in my "stragglers" file in my records, which is for people whom I had to grade their Quizzes manually. (If you submitted your electronic file late but had previously received your grade from me, that means it was done in my semi-automatic grading last week, because you submitted it before I collected the files from handin.) Though there were only 4 of them, it took me longer to grade, record and e-mail results than it had for the entire class in the semi-automatic grading. This of course defeats the purpose of the latter, so please try your best to remember to get your electronic files in on time. Thanks.

Thursday, Oct. 31, 4:35 p.m.

As a skeptic on MOOCs, let me raise the following question: If remote online instruction is so great, why was Thrun coming in person to speak in the first place? Why not an online interactive Webinar? :-)

Wednesday, Oct. 31, 4:32 p.m.

Unfortunately, the talk on MOOCs scheduled for tomorrow has been canceled. There are plans to reschedule it, but meanwhile there is the question of what to do with all the cookies the department had ordered for the talk. :-( Here is the official announcement:

Unfortunately this talk is cancelled and will be rescheduled soon. However please join us for a pre-Thanksgiving get together at 4pm in the Kemper Lobby. We can't let all those cookies go to waste :-)

Consider it a belated Halloween treat. :-)

Tuesday, Oct. 30, 11:02 p.m.

Hwk 3 is basically ready. I'll have Matt check it over for typos, etc., but it's ready for you to start.

Each of the subroutines should turn out to be pretty short, probably under 20 instructions. But there are a number of aspects which may be conceptually difficult. So, START EARLY! Matt and I will give you help if you need it, but as you know, that won't work at the last minute.

Monday, Oct. 29, 5:52 p.m.

The talk on MOOCs, which I discussed earlier, will be given this Thursday. Note that it is in Giedt Hall, not the usual place for our Thursday colloquia.

Monday, Oct. 29, 9:52 a.m.

If you have turned in any of your Quizzes late, please re-read (or read) the blog entry of Oct. 21, 11:10 p.m.

Sunday, Oct. 28, 10:27 p.m.

There will be no Quiz this week. Instead, Matt will give a minilecture. This will be treated as regular course material, eligible for Test questions, so make sure to be there. (He'll give the same minilecture on Tuesday and Wednesday.)

Sunday, Oct. 28, 5:17 p.m.

You will not be held responsible for Sectioins 7.8.8.5 and 7.11.

Sunday, Oct. 28, 11:56 a.m.

To print a number in hex form in R, use as.hexmode(). For instance:

> as.hexmode(18)
[1] "12"

(In R, the as*() family of functions serve similar to casts in C.)

Sunday, Oct. 28, 10:40 a.m.

Someone asked me yesterday whether most people did poorly on the Wednesday Quiz 3. Since others may be interested in the answer, here it is: Out of 27 students, 5 got As and 10 got Bs. (These include + and - grades but do NOT include the recent "blog bonus.") There were two 100s. I haven't tabulated the Tuesday results, but they look similar (a quick glance shows three 100s).

In my classes, the average final course grade tends to be around 3.0-3.2. This is higher than the university-wide average of 2.7, but there does tend to be considerable variation, as each class has a different "personality." I just checked my Spring 2010 ECS 50 grades, and they were quite good: 15 As and 17 Bs out of 41 students.

Note that for most students, the final course grade they get in my class is higher than their Quiz average. This is because (a) most students get an A or A- average on their Homework and (b) you get to drop your 2 lowest Quiz grades.

If you have any questions on these or other issues, please feel free to discuss them with me.

Saturday, Oct. 27, 9:53 a.m.

You are required to read our blog every day. In order to stress this point, I am making the following offer: If you send me e-mail by Monday 11:59 p.m. and specify a Quiz number (1, 2 or 3), I will increase your grade on that Quiz by 1.0 grade point. For instance, a B- would become an A-. (An A- or A would become an A+.)

Tuesday, Oct. 23, 9:14 p.m.

Reminder: When submitting your electronic Quiz file, the file name must be x.txt, where x is your official UCD e-mail address that shows up on my enrollment list, e.g. kcjones.txt. Otherwise the automatic grading program will miss your Quiz, and count it as an F when computing course grades at the end of the quarter.

Monday, Oct. 22, 11:27 p.m.

Quoting from our Syllabus:

I aim for the vast majority of the class to get an A or A- on the Homework. Lots of help is available, so this aim should be achievable. And it is; I use this policy in every course I teach, and it always works out that most people get A or A- Homework grades.

The most important part of getting a good Homework grade is to start an assignment as soon as it is assigned. Don't wait until a few days before the due date to start. And make sure you have read the textbook thoroughly before starting.
Monday, Oct. 22, 10:57 a.m.

I've now posted the solutions to Quiz 2.

Monday, Oct. 22, 10:45 a.m.

On p.105, "because 0xfffffffd has a 0 at bit position 2 and all 1s elsewhere" should refer to position 1, not 2.

Sunday, Oct. 21, 11:10 p.m.

If you turn in your electronic Quiz file late (via e-mail, as required for late submissions), it may be a while before it is graded. It WILL be graded, but I typically will not get to it until some time later.

Saturday, Oct. 20, 7:14 p.m.

At the request of the Student Disability Center, I am posting their message:

The Student Disability Center asks that students interested in serving as paid notetakers for this course please contact Russ Zochowski at rjzochowski@ucdavis.edu. Notetakers are paid a stipend of $25 per unit, but must have a social security number in order to be paid. Students are asked to put notetaker, the course title, number, and instructor’s name in the subject lines of their emails. Their information will be passed along to the SDC student in need of notes, and if they are interested they will contact each student accordingly.
Thursday, Oct. 18, 11:27 p.m.

In your electronic Quiz files, note the following: If a problem calls for multiple answers, e.g. multiple blanks in a fill-in question, BUT does NOT have explicit parts (a), (b) and so on, please do not make up your own. It will drive the grading program crazy. Just put all your responses on one line, separated by some delimiter such as spaces or commas.

Thursday, Oct. 18, 10:51 p.m.

I've now graded the Quizzes for both days. Please let me know if you do not receive your grade by e-mail.

I'll be going out of town, so it will probably be a couple of days before I post the solutions.

Thursday, Oct. 18, 11:00 a.m.

If you forget to submit your electronic Quiz file on the same day as the Quiz, it WILL be graded, without penalty, but you will need to e-mail it to me instead of submitting it to handin.

Thursday, Oct. 18, 10:55 a.m.

I urge everyone to attend the talk by Sebastian Thrun on November 1 (I had originally thought it was today), on MOOCs (Massive Open Online Courses). It will be in 1065 Kemper Hall at 3:10. MOOCs have been the topic of spirited debate among our CS faculty in the last couple of months, with strong opinions on both sides.

Regardless of your views on MOOCs, you definitely should go hear Dr. Thrun speak. He's very famous, including for development of the Google driverless car, and as part of your college experience you should go hear as many famous people as possible. Watch how they think, how they speak, the nature of their demeanor; that is indeed an education.

I happen to be on the anti-MOOC side, because I believe it will result in shallower courses with shallower homework and exams; in my view, it's just a way for universities to save money, and for some individuals to make money. It might be fine for very mechanical subjects involving rote memorization, but that is not what a university course should be, IMHO. I'm all for making course materials available to the world, but as you know, I already do that on the Web; one doesn't need MOOCs for that.

Wednesday, Oct. 17, 5:01 p.m.

If a problem on a Quiz has no (a) and (b) labels, the answers must be on ONE line, not two. E.g. today's Quiz, Problem 1.

Wednesday, Oct. 17, 1:41 p.m.

In the solution of Problem 5, Wednesday Quiz 1, I had originally written 6 x 224. It should be 2 x 224. If you had the latter answer and were misgraded, please let me know. If you had the former answer, it is my policy never to deduct points ex post facto.

Tuesday, Oct. 16, 9:14 p.m.

Oops! I meant "not hard" below, not "now hard." :-)

As I said in class today, Matt decided to try writing writesa() himself, and it ended up about 600 lines long, including comments and blank lines. I think that much of that is redundant code, so that making subroutines out of the redundant code would make things much shorter. There should be something like 2-3 cases for writing a 1, and about the same for writing a 0.

Tuesday, Oct. 16, 7:50 p.m.

As noted earlier, writesa() will now be Extra Credit rather than required. I mentioned before that writing the function is now hard [later correction: NOT hard], but there are several different cases to consider. If you get one case working involving writing a 1, and one case working involving writing a 0, you will receive Extra Credit. If you get all cases working, you'll get super Extra Credit.

I strongly urge you to pursue this Extra Credit, because as mentioned, the code is not difficult conceptually; there are simply a number of cases to consider.

Extra Credit does matter--a LOT. I use Extra Credit to bump up students' course grades, and to write letters of recommendation in the future.

Tuesday, Oct. 16, 5:56 p.m.

After much thought, I've decided to make the writesa() portion of the Homework Extra Credit. Details to follow. (After the debate.)

Monday, Oct. 15, 1:36 p.m.

In Section "pi," i.e. 3.14, the goal of the program may not be clear. It is to count how many 'a' characters there are in the given string, how many 'b' and so on.

Monday, Oct. 15, 12:02 a.m.

Here are some tips that may help you with the writesa() part of the assignment.

Sunday, Oct. 14, 11:24 p.m.

Please note carefully a change in handin procedures for Quizzes. From now on, the directory names will reflect Tuesday and Wednesday discussion sections. This coming week's Quiz will use 50quiz2tues and 50quiz2wed, for example.

Sunday, Oct. 14, 10:18 p.m.

I'm mailing out the Wednesday Quiz grades now. The grades were not as good as Tuesday's, an odd result since I thought Wednesday's version was a bit easier, but extra points on Problem 3 compensates to some degree.

Sunday, Oct. 14, 7:51 p.m.

I have now graded the Tuesday Quiz, and the grading program automatically e-mailed out the scores. Please note that the entire process is only semi-automated; a human, i.e. me, looks at every single question in every file.

The results were generally quite good, very nice to see. Note that the syllabus welcomes you to suggest that you may deserve more points on some problem.

If your electronic copy of the Quiz had format errors, a penalty was imposed on you, typically 10 points. You can cancel the penalty by e-mailing me (don't use handin for this particular purpose) a correctly-formatted copy of the file. Also, if you had invalid R expressions, you might have not had a penalty imposed but still may have lost points, so see the above remark regarding the syllabus.

Saturday, Oct. 13, 7:51 p.m.

Matt decided to write the code for writea(), and found, not too surprisingly, that it was much, much longer in terms of number of lines. But again, this is due to the fact that you have to account for a number of different cases.

Exploit that latter fact! Arrange for each person in your group to handle different cases.

Saturday, Oct. 13, 10:51 a.m.

We've already seen several jump instructions, and will soon see more. You will probably find it helpful to make a list of the ones we've covered through next Tuesday, so that you will have it handy on the Quiz. You will be asked to write some code on this and other Quizzes, and jumps will play a prominent role. So, having a list handy could save you a lot of time flipping through pages in the book. In fact, you might want to make a list of instructions as well.

Friday, Oct. 12, 5:51 p.m.

At Matt's suggestion, I've extended the due date by 3 days. Matt feels that the writesa() code is pretty difficult. I did say in class that it would be more difficult than readsa(), but I should clarify what I meant: It's not more difficult conceptually, but there are more cases to handle.

In any case, please don't treat the 3-day extension as meaning you can start 3 days later. :-)

Friday, Oct. 12, 1:26 p.m.

If you submitted an incorrectly-formatted electronic file for your Quiz this week, there is still time to AVOID A GRADING PENALTY. Please see our course Syllabus for the correct format. Note that I posted a reminder about this here on the blog, October 6, 9:40 p.m.

Normally I will grade the Quizzes within 1 or 2 days. This week has been a time crunch for me, so it will be another 1 or 2 days before I get to it, and thus you have time to resubmit.

Side note: I serve as a job reference for many students, and I can tell you that the question employers ask me first and foremost about a student is, "Is this person reliable?"

Thursday, Oct. 11, 10:03 p.m.

You are all experienced programmers, and you know that functions should be self-contained as much as possible. In doing the current homework, and those that will follow, this principle will be especially important to keep in mind, for the following reason.

Recall the discussion in class today, which involved the fact that the the machine level (meaning assembly language level, which is the same) there is no notion of scope. In C/C++, scope is an imaginary though very useful concept, enforced by what the compiler will allow you to do; if you violate scope rules, the compiler will simply refuse to translate your C/C++ code to machine language. But the machine itself has no such concept; any spot in memory is visible from anywhere in your code (except for OS-set permissions, which we'll discuss later in the course).

So, in working at the assembly level, you need to be extra careful not to make unreasonable violations of the self-contained nature of functions. For example, say in your "main" program, where you'll test readsa(), you have a label test1. Then you certainly would NOT want to have any references to test1 in your readsa() code, which would ruin the general applicability of that code.

Thursday, Oct. 11, 11:57 a.m.

Homework 2 is basically ready. Matt won't have a chance to look it over for typos etc. for a while, but it is ready to go.

PLEASE GET AN EARLY START! There is a lot of new material to learn, and the coding is not easy, especially for the setter. To gauge the difficulty of the assignment, I wrote the getter yesterday. It only took about 25 instructions (not 25 lines), but it's not easy, and the setter is considerably harder.

Monday, Oct. 8, 6:24 p.m.

Please, please use a debugging tool in all of your programming, not just for our class. As I said, this is to help YOU, not me. Trust me: once you learn how to use it skillfully, it will save you time.

Two students came to my office today with a weird error in their program. They were nice, friendly people, and I'm happy to help them. But the WAY that I used to help them was to use GDB. I found the first trouble spot within a couple of minutes, and it would be easy to track down the bug from there (using GDB some more). This works, trust me!

Monday, Oct. 8, 10:44 a.m.

Please remember that you must turn in the electronic version of your Quiz on the same day as the Quiz.

Sorry for posting so many messages regarding Quizzes, but I know you want to do well, and I want you to do well.

Sunday, Oct. 7, 5:19 p.m.

If you missed class, you may not know that Chapter 2, Components of Computer "Engines," is assigned as reading. It will not be covered in class, but will be used a lot and will appear in Tests.

As mentioned in the Syllabus, coverage for a Quiz will consist of all material covered previously, including the most recent lecture. However, typically the latter will be covered only lightly, if at all.

Saturday, Oct. 6, 9:40 p.m.

In order to avoid having points deducted from your Quiz score, it is important that the electronic answers file that you submit after the Quiz comply fully with the specs in the Syllabus. See the ECS 132 blog (Oct. 6, 9:38 p.m.) for an example of a file with numerous problems.

Saturday, Oct. 6, 11:30 a.m.

Please keep in mind during Quizzes that you need to make a copy of your answers before submitting your papers. Again, you can not use your cell phone to do this, but the answers will be very short, so copying by hand will be quick and easy.

Friday, Oct. 5, 10:40 p.m.

As our first Quiz approaches, please review the Honor Code issues discussed in Sec. 11 of our Syllabus. In particular, remember that no electronic devices may be used of any kind. Please do not use your cell phone etc. until you are outside the room after the Quiz.

Thursday, Oct. 4, 10:40 p.m.

Due to a couple of questions that I've been asked today, I'd like to remind everyone that this is not a programming course. We definitely do a considerable amount of programming, but it is a means, not an end; the programming is used as a vehicle to learn about the machine.

One implication of that is, alas, we won't be writing dazzling programs such as games and the like. Another implication, which I will focus on here, is that there usually won't be any "output" in the usual sense.

Consider the current assignment, for instance. One of our goals is to learn about how two-dimensional arrays are stored at the memory level. Writing the code for the smatrix class is an exercise aimed at such learning. As such, there really isn't any "output," beyond checking that your code produced the right results.

What I did to check that cmatrix was correct was quite simple: I ran the program through GDB, and used the latter to print out cmatrix. Alternatively, I could have used printf() or cout. It's up to you.

Thursday, Oct. 4, 7:40 p.m.

You are not responsible for Sec. 1.11. It's too complex, and in fact I've deleted it from the updated version of the book.

Recall that although you are NOT responsible for the updated version, I often correct errors in it and clarify things. So if you're unsure of something in the official version, you might check the revision.

Thursday, Oct. 4, 2:12 p.m.

CSIF set up Matt's handin account under cs50, not mfbutner. So, you submit your work by typing

handin cs50 50hwk1 jsmith.agutierrez.streddy.tjwong.tar

of course with your own group name.

Wednesday, Oct. 3, 8:07 p.m.

In response to a couple of questions on the Homework:

Wednesday, Oct. 3, 3:57 p.m.

Please recall that we use handin to submit both Quizzes (electronic copies) and Homework. Note carefully that you submit the former to me and the latter to Matt, our TA. To make sure you get credit for your submission, it's crucial to you follow the procedure exactly.

For a Quiz, you type this on CSIF, say for the first Quiz:

handin matloff 50quiz1 jsmith.txt

Here you replace jsmith with your official UCD e-mail address (minus the UC Davis suffix).

The procedure is the same for submitting Homework, except that you submit to mfbutner instead of matloff, and your file name conforms to the specs in our course Syllabus.

Wednesday, Oct. 3, 1:57 p.m.

I've mentioned several times that the title of this course includes the phrase "machine dependent," where machine means both the high-level hardware and the operating system. For us, that means Intel (or Intel clone, e.g. AMD) and Linux. I've gotten a couple of questions recently on platforms for this class, and as others may have such questions, I'll post my answers here.

Tuesday, Oct. 2, 11:22 p.m.

A little more on submitting your electronic file: No need to simplify numerical expressions; as long as your R code gives the right answer, it's fine.

Tuesday, Oct. 2, 10:32 p.m.

Be sure to carefully review the procedures for quizzes before next week's discussion, when we'll have our first quiz.

In particular, numerical answers must be expressed in terms of executable R code, e.g

5 * 2^(-2)

for Equation (1.2). Run the R code before you submit your electronic file if you are unsure. (Just type "R" on the command line on a CSIF machine, enter the R expression and hit Enter.)

Note too that your electronic file must match your paper submission exactly; no revisions of any kind are allowed.

Monday, Oct. 1, 9:25 p.m.

Hwk due date Oct. 8.

Monday, Oct. 1, 7:00 p.m.

In the sm1 example in the homework, thre is only 1 clump.

Sunday, Sept. 30, 4:52 p.m.

Our TA Matt asked me to point out that when using a debugging tool, one of the most common operations is to print the value of an array. Here for instance, is how one can print out one of the items in the example in our homework specs, using GDB:

(gdb) p *sm3.cmatrix@6
$2 = {1, 1, 3, 1, 5, 4}

Here I instructed GDB to print the first 6 elements of the array sm3.cmatrix.

I cannot emphasize the debugging issue enough. In my experience, only a minority of students use a debugging tool; the rest learn, say, GDB because it will be on the final exam in ECS 40, but then never use it afterward. The reason you should use a debugging tool is not to please me or, say, Sean Davis; you should use it because effective use of a debugger will SAVE YOU TIME AND FRUSTRATION.

Which tool you use, of course, is up to you. Some of the most popular (cross-platform) debuggers in the real world are GDB, Eclipse (IDE), Emacs and so on. GDB is literally the most basic, as it is used by many of the others internally. On Unix-family systems such as Linux, my favorite is DDD, though I just use GDB (with TUI; see our text or the above link) for small programs; it's available as ddd on CSIF.

Sunday, Sept. 30, 2:12 p.m.

Hwk1 is ready.

Sunday, Sept. 30, 12:02 p.m.

Unfortunately, I will not be able to meet my office hour tomorrow, Oct. 1. I have a department meeting for which no other time could be found. I will however be available via e-mail.

Sunday, Sept. 30, 10:02 a.m.

Hwk1 is basically ready. Our TA Matt is looking it over for errors or ambiguities, and I may add one or two more methods to the class, but it is basically ready for your programming pleasure :-) .

Saturday, Sept. 29, 7:31 p.m.

Please note that a homework assignment is not official until it is announced. I have a half-finished problem up there now, which you are welcome to look at, but it is definitely still a work in progress.

Friday, Sept. 28, 4:31 p.m.

Please note my and the TA's office hours are shown in our class Web page, http://heather.cs.ucdavis.edu/~matloff/50.html