Archive for January 31st, 2008

Background scores of movies

January 31, 2008

Some of the finest background scores for movies I have heard are from Ilayaraja. I used to love the score he made for the Malaylam movie called Guru, in which, when the protagonist moves from our world to another in which people lack the sense of sight and hence carry out all their activities based on sound and vibrations, the background score also glides and becomes exotic and fantastic.

However, there aren’t many Hollywood movies that I can think of, the background score of which, did impress me (There are exceptions, of course; Ronin is one that comes to my mind immediately).

Alex Ross, in his latest New Yorker piece seems to agree that Hollywood does not pay much attention to background score, but has some nice things to say about the background score of the movie There will be blood:

There may be no scarcer commodity in modern Hollywood than a distinctive and original film score. Most soundtracks lean so heavily on a few preprocessed musical devices—those synthetic swells of strings and cymbals, urging us to swoon in tandem with the cheerleader in love—that when a composer adopts a more personal language the effect is revelatory: an entire dimension of the film experience is liberated from cliché. So it is with Paul Thomas Anderson’s movie “There Will Be Blood,” which has an unearthly, beautiful score by the young English composer Jonny Greenwood. The early scenes show, in painstaking detail, a maverick oilman assembling a network of wells at the turn of the last century. Filmgoers who find themselves falling into a claustrophobic trance during these sequences may be inclined to credit the director, who, indeed, has forged some indelible images. But, as Orson Welles once said of Bernard Herrmann’s contribution to “Citizen Kane,” the music does fifty per cent of the work.

Take a look!

Update: Jan Swafford reviews the soundtracks of No country for old men and There will be blood:

This winter produced two epic Westerns, both powerful and unconventional, both filmed in the same landscape, similar in some dimensions and contrasting in others. No Country for Old Men and There Will Be Blood present visions of the American dream gone haywire, one in orgies of killing, the other in a labyrinth of greed and madness. One thing that unites them is how all the elements of their soundtracks—dialogue, effects, music—work together to shape the story. What divides their approach to sound is that Jonny Greenwood’s score for Paul Thomas Anderson plays out in the usual musical fashion if not with the usual sense, while the Coen brothers created a soundtrack of great expressive effect with next to no “music” at all.

Take a look!

A recommendation for Conan Doyle’s Brigadier Etienne Gerard series

January 31, 2008

I knew of Conan Doyle’s Holmes novels and stories; I also liked his Lost world, which I read it in tamil translation ages ago. However, I did not know about his Brigadier Etienne Gerard series; over at NPR, Michael Chabon strongly recommends these stories:

But did you know that in between gleefully killing off Holmes and somewhat reluctantly reviving him, Arthur Conan Doyle created another great fictional character, one who easily rivals Holmes — if not for intelligence, then for heroism, bravery and dash? A character who exceeds Holmes in the one trait in which the great detective, by his own admission, was always deficient: a rich and lovable humanity. This hero, a handsome, charming and resourceful cavalry officer serving in the Grand Army of Napoleon, has only one tragic flaw, though in his own eyes, of course, it is his glory and his single greatest advantage in life: He is a Frenchman.

His name is Brigadier Etienne Gerard, and he starred in 17 short stories that Conan Doyle wrote, with a palpable sense of liberation, after pushing Holmes off that Alpine ledge. In their day they were almost as popular as the Holmes stories, but I have to confess that even though I’m a lifelong Sherlockian, I had never heard of the good brigadier until his exploits and adventures were recently collected in a single volume.

In its pages you will find adventure, action, romance, love and self-sacrifice, hair’s-breadth escape and reckless courage, gallantry, panache and a droll, backhand humor that rivals that of P.G. Wodehouse. You will also find yourself, even more than with the celebrated stories of Holmes and Watson, in the hands of an indisputable artist. For more than any other adventure stories I know, these stories have a power to move the reader.

There is a very long excerpt too from the recent collection of this series; have fun!

How big is too big?

January 31, 2008

Recently, I have been trying to see how large a memory chunk I can allocate using malloc. Rather, I was trying to allocate more than twenty large chunks of the order 0.1 GB or so, and my desktop  (Mac 4 x 2.5 GHz PowerPC G5, with 4 GB DDR2 SDRAM) was giving up with error messages of the  following type:

muse_evolver_fftw.out(2491) malloc: *** vm_allocate(size=268435456) failed (error code=3)
muse_evolver_fftw.out(2491) malloc: *** error: can’t allocate region
muse_evolver_fftw.out(2491) malloc: *** set a breakpoint in szone_error to debug
Bus error

So, I wanted to figure out the limit (as well as a solution — if there is a way to overcome the limitations, if any).

After a bit of Googling, I found that Chris Adams, in his page, gives a C code which you can compile and run on your machine to figure this limit; I compiled and ran the code on my desktop and got the following output:

Determining maximum single allocation: block size = 65536, memset=0
maxmalloc(4123) malloc: *** vm_allocate(size=2363490304) failed (error code=3)
maxmalloc(4123) malloc: *** error: can’t allocate region
maxmalloc(4123) malloc: *** set a breakpoint in szone_error to debug
Maximum single allocation: 2.20Gb (36064 65536 blocks)
Determining maximum allocation size: small block size = 1024, memset=0
maxmalloc(4123) malloc: *** vm_allocate(size=8421376) failed (error code=3)
maxmalloc(4123) malloc: *** error: can’t allocate region
maxmalloc(4123) malloc: *** set a breakpoint in szone_error to debug
Maximum total allocation: 1.00Gb (1777660 1024 blocks)

Thus, though the physical memory available to me is large, malloc gives up within 25 to 50% of that memory usage.

The fact that malloc has an upper limit in the memory it can allocate has a say in how large a simulation I can run, since, I run 3D simulations using FFTW. One of the easy ways in which you can make FFTW run faster is by using threads — it just requires few extra lines in your code and can speed up the calculations quite a bit; however, such shared memory parallelizations seem to have a problem when one has to run simulations on large system sizes. In such cases, it might be essential that I distribute both memory and processes — in other words, use MPI and such parallelizations. For now, I have overcome the problem partly, by malloc-ing and free-ing the memory so that at no time I have such a large number of arrays in memory. This seems to mitigate the problem a bit, albeit, at the cost of such frequent allocations and freeing.

Disclaimer:  I do not know much about malloc, its limits, shared memory and distributed memory processes. All of the above, I gathered via Googling. So, if any of you find any mistakes in what I have written above, and/or have solutions for my problem, please feel free to put a note below in the comments. I will hoist them to the post.