Saturday, May 31, 2008
Picnic at Castle Rock
My hike left me in a much lighter mood than the "Hanging Rock" movie. I went there on a Friday afternoon (Yup, had the day off) at around 2 PM. This place is just 35 mins away from my place. But then, aren't most parks in the Bay Area just 35 mins from where you live ;-) It was a bright, sunny afternoon. Very few people around. I couldn't have asked for more. I did the Falls -> Goat rock loop. I didn't venture into the Ridge trail. I'll do it another time.
If you are driving down 85S, use Saratoga Ave instead of 17 - which is what most Maps suggest. Saratoga (CA 9) is a more peaceful drive, quite narrow roads and you'll enjoy it if there aren't many cars on the road.
Monday, May 26, 2008
Blue tailed bee eaters
Blue tailed bee eaters, Naguvana halli, originally uploaded by SRJP.
Pic taken by my dad - Dr Jayaprakash, Bangalore
Monday, May 12, 2008
Memory - don't forget it hurts
I as a Java programmer have often wondered, don't long running programs/servers written in C/C++ have issues with memory allocation at all? I'm not talking about very special programs that you really wouldn't care writing in any language other than Assembly like - bit transferring or blitting or something low really level. I'm talking about medium to large scale applications with lots of business logic, decent concurrency requirements ... the kind of programs Java and .Net are used widely for.
It turns out that leaving memory allocation completely to the programmer is a pain in the backside. Without a managed runtime, any good engineering team using C/C++ ends up either developing their own memory allocator or buying one, because most of the allocators that come with the standard compiler kits have problems with scalability on multiple-cores/cpus/threads and over a period of time the heaps become fragmented.
And this is not just ordinary software - I'm talking about Video Games written in C/C++. It's interesting to read this - GameDevBlog: STL & Memory allocation on consoles and about efforts going on to make FireFox 3 better.
Now Java, on the other hand, which is supposedly (to the semi-ignorant folk) slow has a great choice of allocators - many of which work well on multicore platforms. The other advantage (depends on which way you look at it) is that fragmentation is less of a problem with "Copy collectors". And with the new Generational GCs rapid, consecutive allocation of temporary objects is actually very fast in Java. Plus there are other GC settings to choose from. Agreed, there is plenty of room for improvement - which is why Sun is working on the G1 Collector and let's not forget the Real-time JVM.
Before you go, here are a few more articles to read in your next coffee break. Just to understand how well Java's HotSpot has improved over the years:
# Java running faster than C
# Compiler Intrinsics
Wednesday, May 07, 2008
Saturday, May 03, 2008
Subscribe to:
Posts (Atom)