eeePC 901
March 4, 2010
I got a while back this ASUS eeePC 901, with a 1.6ghz Atom and 20GB of SSD. When I first got it I upgraded the RAM to 2GB, and installed Windows XP. It wasn't that great, so then I tried Win7 pro on it, which almost worked, but would just freeze for lengths of time for no apparent reason. The keyboard is tiny and has a very different arrangement from what I'm used to. It sat idle for a while, and since I have been developing on Linux (hello, SWELL/generic), I decided to install Ubuntu on it. The new verdict:
March 4, 2010
I love it. It's reasonably fast for compiling, installing new stuff is easy (apt-get ftw), Firefox w/ flash is fine, Xchat is decent enough, the stock mail client is very usable. The best part is that the battery life is fantastic, the screen is bright, there are very little moving parts, and it feels really solid. Yes, a bit like a toy, but I'm not worried about breaking it. Anyway, I'm fully on board with the netbook thing. Maybe next time I'd get one with a slightly larger keyboard, though...
Oh yeah and the other part of what I'm saying is: I'm definitely appreciating where Linux distributions for the desktop have gotten. Almost there... ;)
which reminds me: strict aliasing
March 4, 2010
I get that the "strict aliasing" optimization of recent C/C++ standards allow for great optimization. And I get that gcc has some anciently-designed optimizing, but at any rate, it annoys me that gcc will detect strict-aliasing violating code, and still go ahead and generate code that is obviously wrong -- i.e. when it knows that two pointers ARE in fact pointing to the same memory, it assumes that they can't possibly, and optimizes as if they don't. LLVM probably doesn't have the same problem, heh. Oh well I'll use -fno-strict-aliasing and meanwhile go through and use unions (and occasionally C++ templates) to make our stuff compatible with strict aliasing optimizations.
March 4, 2010
Of course, on performance sensitive code this is a huge time sink -- I ended up (on our anti-denormal code) looking at the output of many iterations of the same code on gcc i686, x86_64, vc6+icc10, vc2005+icc10, icc11 on osx, gcc ppc, etc, to try to find source code that worked properly and produced decent assembly code. The variety of code produced by each combination is staggering. Also, I found that often the code I thought would be fastest was not, when benchmarked. Oh well.
Posted by richard stallman's beard on Fri 05 Mar 2010 at 16:46 from 95.42.85.x
Posted by Andrew on Sat 06 Mar 2010 at 00:26 from 24.5.111.x
Posted by lii on Sat 06 Mar 2010 at 02:11 from 95.42.85.x
Posted by lii on Sat 06 Mar 2010 at 02:14 from 95.42.85.x
Posted by Malcolm on Sat 06 Mar 2010 at 13:09 from 118.208.8.x
Posted by AnalSeducer on Sun 07 Mar 2010 at 15:49 from 71.142.81.x
Posted by lubo on Sun 07 Mar 2010 at 17:03 from 95.42.85.x
Posted by furn on Tue 09 Mar 2010 at 19:41 from 98.117.124.x
Posted by fladd on Tue 23 Mar 2010 at 16:37 from 82.174.120.x
Add comment: