Nicolás Brailovsky


A modern blog

Dell and Ubuntu CPU Scaling

author Posted by: nico on date Oct 20th, 2011 | filed Filed under: Grumpy, Linux
Hi, my name is Nicolás Brailovsky and you may remember me from movies like fixing keyboard problems in Ubuntu JJ, removing the annoying terminal warning, random complaints about dual screen in Buguntu and Ubuntu: sound still fubard. This time, I would like to add a new Ubuntu problem to the list of things which make me want to jump off a cliff, though I must warn you that this is a very old article that got forgotten on the stack of posts to review, so it might be dated. Being an old post means that this problem may be fixed by now, but since I don’t have a Dell laptop anymore I cannot try it. Anyway, I’ll post it as a reference to anyone who may experience something similar.

To be completely fair, this is a dual fuckup between Dell and Ubuntu: after an upgrade I started noticing that sometimes the CPU slows to a crawl, for no apparent reason. The only fix for this is a complete shutdown, as not even a reboot would make this problem go away. WTF?

A lot of time after I had given up on trying to solve this problem and decided that submitting to the gods seemingly random will was the best option, a coworker told me what this was about: apparently when you have a 3D GUI (say, a screensaver) and a double monitor the graphics card has to “work too much”, drawing too much power. When the power consumption reaches 90 watts, the power supply’s limit, the CPU enables something called CPU scaling, bringing the CPU clock speed to about the speed of a wristwatch. (No, really: “Even setting aside the negative performance effect of FSB downshifting in II above, the effective processing power is reduced to 1/8 of 798 Mhz = 100 MHz. This is a reduction to less than 5% of full capacity, from http://www.sigmirror.com/files/44490_iweoz/throttlegate.pdf).

Solution? None, thanks. Just shut it down and reboot.

Cool C++0X features XV: Initializer lists for custom (non-std) objects

author Posted by: nico on date Oct 18th, 2011 | filed Filed under: C++0x

Last time we saw how you can use C style array-initialization for C++ objects, like this:

  1.         std::vector<int> v = {1,2,3,4};

We also saw this works for may types of objects, like maps and pairs. How about custom developed objects? Yes, that’s right, you can have initilizer lists for your own objects too, and it’s quite easy. C++0x offers initializer_lists which you can use on your constructors (or any other methods, for that mater) to have C-style initialization. Let’s see an example. We already know how to sum a list of numbers using template lists and variadic templates, so let’s try adding an initializer consisting of numbers:

Let’s start by creating a class which can accept an initializer list:

  1. #include <initializer_list>
  2. using namespace std;
  3.  
  4. struct Add_List {
  5.         Add_List(initializer_list<int> lst) {
  6.         }
  7. };
  8.  
  9. int main() {
  10.         Add_List x = {1, 2, 3};
  11.         return 0;
  12. }

That’s interesting, as you can see an initializer list is actualy a template class, meaning that nested initializers can easily be defined too. Now, we have the interface, how can we access each element of the list? Let’s do the same thing I did when I found out about initilizers, let’s search for the header file.

  1.  template<class _E>
  2.     class initializer_list
  3.     {
  4.     public:
  5.       typedef _E                value_type;
  6.       typedef const _E&amp;     reference;
  7.       typedef const _E&amp;     const_reference;
  8.       typedef size_t            size_type;
  9.       typedef const _E*         iterator;
  10.       typedef const _E*         const_iterator;
  11.  
  12.     private:
  13.       iterator                  _M_array;
  14.       size_type                 _M_len;
  15.  
  16.       // The compiler can call a private constructor.
  17.       initializer_list(const_iterator __a, size_type __l)
  18.       : _M_array(__a), _M_len(__l) { }
  19.  
  20.     public:
  21.       initializer_list() : _M_array(NULL), _M_len(0) { }
  22.  
  23.       // Number of elements.
  24.       size_type
  25.       size() const { return _M_len; }
  26.  
  27.       // First element.
  28.       const_iterator
  29.       begin() const { return _M_array; }
  30.  
  31.       // One past the last element.
  32.       const_iterator
  33.       end() const { return begin() + size(); }
  34.   };

Looks surprisingly easy (note that this is for G++ 4.something only). And it is, most of the magic happens in the compiler, so the userland code is quite straight forward. According to that header file, we could build something like this:

  1. #include <iostream>
  2. #include <initializer_list>
  3. using namespace std;
  4.  
  5. struct Add_List {
  6.         Add_List(initializer_list<int> lst) {
  7.                 int sum = 0;
  8.                 for (auto i = lst.begin(); i != lst.end(); ++i)
  9.                         sum += *i;
  10.  
  11.                 cout << sum << "\n";
  12.         }
  13. };
  14.  
  15. int main() {
  16.         Add_List x = {1, 2, 3};
  17.         return 0;
  18. }

As you can see, the initializer lists can be used in any place an iterable container is required, as long as it’s const. There’s not much more magic to it, but we can use some more C++0x devices to make our list-adding device much more cool, for example to support different actions and not only addition. Next time, though.

PS: An important lesson from this article: don’t be afraid to look into the system headers, they won’t bite. You should never ever change them, but taking a peek can only improve your C++ knowledge.

Dennis Ritchie > /dev/null

author Posted by: nico on date Oct 13th, 2011 | filed Filed under: Misc

UNIX is very simple, it just needs a genius to understand its simplicity.

— Dennis Ritchie

Starting Ubuntu in console mode

author Posted by: nico on date Oct 13th, 2011 | filed Filed under: Console, Gnome, Linux

Like it or not, Ubuntu is so easy to install that even for servers is very comfortable to just mount the iso and create as many virtual machines as you may need. Sometimes you already have an iso for Ubuntu, but are too lazy to download the server version. For those occasions you can either decide to waste precious RAM running a GUI for a server that will never need it, or you can remove all traces of the graphical login. Like this:

  1. sudo update-rc.d -f gdm remove

This will remove GDM from the startup scripts, meaning you can still fire up the graphical interface (*) if you want, but it will start Ubuntu without loading any graphics stuff. This is very useful to save on RAM, startup time and processing power, which even if not that useful for a desktop machine is incredible beneficial when you have several virtual machines running in a single physical server.

(*) More precisely, if you have users that need it. Remember though, if it can’t be done in console mode, it ain’t worth doing.

http://www.makarras.org/2008/06/17/gandalf/

Cool C++0X features XIV: Initializer lists

author Posted by: nico on date Oct 11th, 2011 | filed Filed under: C++0x

We talked last time about ranged fors and how they can simplify our life in C++0x. Now we are going to take a trip back to old C land. Remember when you could initialize your arrays like this:

  1. int v[] = {1, 2, 3, 4};

C++ brought a lot of changes to the world, and suddenly instead of int[] you were supposed to use vector, and with it your initializer didn’t work anymore. Though luck. Try to compile this:

  1. #include <vector>
  2. int main() {
  3.         std::vector<int> v = {1,2,3,4};
  4.         return 0;
  5. }

If you did compile it with g++, you may have noticed an interesting error message:

  1. error: in C++98 ‘v’ must be initialized by constructor, not by ‘{}
  2. warning: extended initializer lists only available with -std=c++0x or -std=gnu++0x

That’s interesting. Try to compile it with g++ again, but using C++0x instead of plain C++. Magic, now it works!

Initializers lists bring the best of C to C++ world (?) by letting you use initialize any object with an initializer. And I mean *any* object, not just vectors. For example, say you have a map (a map and a bunch of other stuff):

  1. int main() {
  2.         map<string, vector<int>> v = {
  3.                         { "a", {1,2,3} },
  4.                         { "b", {4,5,6} },
  5.                         { "c", {7,8,9} }
  6.                 };
  7.  
  8.         cout << v["b"][1] << "\n";
  9.         return 0;
  10. }

Yes, that works! Maps, vectors, pairs, and even your own custom objects, but we’ll see that next time.

Open Office, master documents and headless

author Posted by: nico on date Oct 6th, 2011 | filed Filed under: Grumpy, LaTeX
I have been writing some documentation lately (crazy, I know) and needed due to some bizarre business requirements all the documentation for the application was supposed to be in a single .doc file. That’s write, a single file for user manual, technical manual, administration manual and so on. And I had no LaTeX either (damn those MS Office files, I hate them) so using multiple tex files and including them together wasn’t an option.

Choosing the least of all evils, I decided to use Open Office and master documents. With them you can create several different .doc files and then join them together in a single .odm file, which can then be exported to pdf (or .doc, if your boss says so). It’s a nice feature, but for such a simple thing as having multiple documents #included in a single one you would expect it to work better. From OO manual:

Yes, master documents do work in OOoWriter. However, their use is full of traps for inexperienced users[...]

Oh, thanks a lot OO.org (?). BTW, exporting an odm to pdf with a headless set == FAIL (i.e. don’t even try to use this if you intend to autogenerate some documentation with your makefile).

Cool C++0X features XII: type inference with auto

author Posted by: nico on date Oct 4th, 2011 | filed Filed under: C++0x, Templates

In the last four entries we worked on a simple example, like the one I’m pasting below, of type inference with decltype, which led us to learn about delayed type declaration and decltypes with auto. This time I want to focus just on the auto keyword instead.

  1. template <class… Args>
  2. auto wrap(Args… a) -> decltype( do_something(a…) ) {
  3.         std::cout << __PRETTY_FUNCTION__ << "\n";
  4.         return do_something(a…);
  5. }

We saw last time how decltype can be used in a contrived way to create a local variable without specifying its type, only how to deduce the type for this variable. Luckily, that verbose method of type declaration can be summed up in the following way:

  1.         int x = 2;
  2.         int y = 3;
  3.         decltype(x*y) z = x*y;
  1.         int x = 2;
  2.         int y = 3;
  3.         auto z = x*y;

That’s right, when you are declaring local variables it’s easier and cleaner to just use auto. This feature isn’t even “in the wild” yet, so you can’t really predict what will people do with it, but it seems to me that limiting its use to local variables with a very short lived scope is the best strategy. We are yet to see what monstrosities the abuse of this feature will produce, and I’m sure there will be many. Regardless of their potential to drive insane any maintainers, its best use probably comes in loops.

In any C++ application, you’ll find code like this:

  1. for (FooContainer<Bar>::const_iterator i = foobar.begin(); i != foobar.end(); ++i)

This ugly code can be eliminated with something much more elegant:

  1. for (auto i = foobar.begin(); i != foobar.end(); ++i)

Looks nicer indeed, but we can improve it much further with other tools. We’ll see how the next time. For the time being, let’s see for waht what auto is not to be used.

When using auto, keep in mind it was designed to simplify the declaration of a variable with a complex or difficult to reason type, not as a replacement for other language features like templates. This is a common mistake:

Wrong

  1. void f(auto x) {
  2.         cout << x;
  3. }
Right

  1. template <T>
  2. void f(T x) {
  3.         cout << x;
  4. }

It makes no sense to use auto in the place of a template, since a template means that the type will be completed later whereas auto means it should be deduced from an initializer.

DIY gnome applets

author Posted by: nico on date Sep 29th, 2011 | filed Filed under: Gnome

We all know Gnome, and similar GUIs, are there only as a fancy console multiplexer, but even so it’s useful to have widgets in your menus or dockbars to display useful data, like the release date of DNF (*). Gnome has a limited amount of applets from which you can choose, and most of them are crap or limited in their customization. You can always create your own widgets, but that’s a pain in the ass for lazy people like me. Fortunately we lazy people can now use something an order of magnitude more useful than widgets in Gnome : we can use console commands!

Using something called Compa you can add a meta-widget, that will display the output of any CLI program. This means, of course, that you have all the power of the console to use in your custom made widgets. Need to check your laptop’s battery? No need to search for a widget anymore, just cat /proc/acpi/battery/BAT0/state. Need to check the weather? Just wget your favorite forecast page and parse it with grep, sed an awk. OK, maybe that’s a little bit too much.

Once more this proves that anything can be done in console mode – and whatever you can’t isn’t worth doing anyway.

(*) Wow, this article has been written a LONG time ago!

Cool C++0X features XI: decltype and disappearing constness

author Posted by: nico on date Sep 27th, 2011 | filed Filed under: C++0x

After a long, long hiatus, the C++0x series are back. You may want to check where we left by reading the last posts of this series.

In the last few entries we saw how to use decltype for type inference. Object types is a problem that seems easy but gets complicated very quickly, for example when you start dealing with constness. Constness is difficult in many ways but this time I want to review how constness works with type inference. This topic is not C++0x specific as it’s present for template type deduction too, but decltype adds a new level of complexity to it.

Let’s start with an example. Would this compile?

  1. struct Foo {
  2.         int bar;
  3. };
  4.  
  5. void f(const Foo foo)
  6. {
  7.         foo.bar = 42;
  8. }

Clearly not, having a const Foo means you can’t touch foo.bar. How about this?

  1. struct Foo {
  2.         int bar;
  3. };
  4.  
  5. void f(const Foo foo)
  6. {
  7.         int&amp; x = foo.bar;
  8. }

That won’t compile either, you can’t initialize an int reference from a const int, yet we can do this:

  1. void f(const Foo foo)
  2. {
  3.         const int&amp; x = foo.bar;
  4. }

If we know that works it must mean that s.result’s type is const int. Right? Depends.

Just as the name implies decltype yields the declared type of a variable, and what’s the declared type for Foo.bar?

  1. struct Foo {
  2.         int bar;
  3. };
  4.  
  5. void f(const Foo foo)
  6. {
  7.         // This won’t compile
  8.         int&amp; x = foo.bar;
  9.         // This will
  10.         decltype(foo.bar) x = 42;
  11. }

That’s an interesting difference, but it makes sense once you are used to it. To make things more interesting, what happens if you start adding parenthesis (almost) randomly? Try to deduce the type of x:

  1. void f(const Foo foo)
  2. {
  3.         decltype((foo.bar)) x
  4. }

If decltype(x) is the type of x then decltype((foo.bar)) is the type of (foo.bar). Between foo.bar and (foo.bar) there’s a very important difference; the first refers to a variable whilst the last refers to an expression. Even though foo.bar was declared as int, the expression (foo.bar) will yield a const int&, since that’s the type (though implicit and not declared, since the expression is not declared).

This is how we would complete the example then:

  1. void f(const Foo foo)
  2. {
  3.         // This two statements are equivalent
  4.         decltype((foo.bar)) x = 42;
  5.         const int&amp; y = 42;
  6.         // It’s very easy to confirm that the typeof x is now const int&amp;
  7.         // This won’t compile:
  8.         x = 24;
  9. }

As I said, disappearing constness is not a C++0x specific problem as it may occur on template type deduction, but that’s besides the point of this post. Next time we’ll continue working with type deduction, but with the new auto feature this time.

Running commands on Windows from Linux, through ssh

author Posted by: nico on date Sep 22nd, 2011 | filed Filed under: Console

Running Windows is something I don’t usually like (running of Windows is a different story) but having to run something on Windows command line interface is something I wouldn’t wish even to my worst enemies. I was stuck in that situation, don’t remember why, but I needed to run a command in a Windows machine, automatically, and I only had ssh (is there a better way of automating scripted tasks in Windows, remotely and without a GUI?). Well, this is what I came up with:

  1. ssh host cmd /c dir

Running that in a bash shell will show the directory listing of C: in machine “host”. Ugly as hell, but it’s a good way of kickstarting a batch script.