tips on ruby embeding

Ruby has more clean and comprehensive object-oriented framework than Python. I started to learn Ruby and embed it with some C program. It is turned out that Ruby is still in its early stage and has lots of stuff to be cleaned. One issue I met is the shebang handling.

In Ruby, when it read the input file, it will check whether the shebang (the 1st if it is started with '#!') refers to itself. Otherwise, it will invoke the shebang to invoke the corresponding executables. But, by "itself", it only refers to "ruby". It will cause errors when your Rub-embedded interpreter cannot be recoganized as "itself." Hence, it is recursively being called and finally fails due to lack of resources.

A simple work-around is to put "ruby" into your Ruby-embedded interpreter name to fake as a Ruby interpreter "itself."

More systemetric solution is to check shebang with argv[0] instead.

TILERA's TILE64 multicore processor

TILE64 multicore processor is announced by TILERA. Compare to Intel's Terascale research prototype, TILE64 not only contains similar number of cores but also has a lot of features.

Amazingly similar, TILE64's interconnect is mesh network which has better scalability than crossbar and better performance than ring. TILE64 features 5 meshes: 2 dedicated for data transfer between tiles and memory (I guess cache-to-cache transfer too.) and other 3 for application use.

The core of each tile is a full featured general-purpose processor compared to other startups' annouced primitive cores. It has not only cache hierarchy but also virtual memory support (MMU and TLB.) The core itself is a 3-way VLIW pipeline. But, most likely, the core should have no FP support considering its current process and targeted applications. The spec says it has totally 5MB cache, each tile likely has 8KB I-cache and 8KB D-cache and 64KB L2 cache (or cache tile.)

Interestingly, TILE64 provide cache coherence and shared L2 cache. It is still unclear how the cache is maintained coherent. But to delivery performance of TILE64, cache hieararchy won't be used for the main data flow due its high latency possibly. Dedicated mesh networks among tiles should be used instead to minimize the cache coherence overhead.

TILE64 provides also friendly developing environment. Linux is ready to run on TILE64.

Till now, only Sun's Niagara2 has comparable features to TILE64 but with a flat memory hierarchy. It is interesting which one is better suited for network processing.

cut vs. awk

I have been igoring 'awk' for a long time and rely on 'cut' to extract section of a file for text processing. But, 'cut' is very limited on the delimiters. However, 'awk' has a more friendly delimiter definition. For example,

| cut -d' ' -f 3
will only treat a single white space as the delimiter, but
| awk '{print $3}'
will treat one or more white spaces as the delimiter and help a lot of output formatted using white space instead of TAB.

Cell vs. GPU vs. CPU

A slide presents transistors and chip area for Cell, GPUs, and CPUs. The following are other resource comparisons I am interested.

	Cell	HPC Cell	Intel Clovertown	AMD Winsor+	ATI R580 X1950	nVidia G80 GTX
Memory on Chip	512KB(L2)+ 256KB(LS)x8	512KB(L2)+ 256KB(LS)x8	4MB(L2)x2	1MB(L2)x2	(TC)	16KBx16(SHM)+ (TC)
Memory off Chip	25.6 GB/s	25.6 GB/s	10.41 GB/s(FSB)	17.0 GB/s (DDR2-1066x2)	64.0 GB/s	86.4 GB/s
IO	25.6 GB/s	25.6 GB/s	10.41 GB/s (FSB)	22.4 GB/s (HT)	4.0 GB/s (PCIex16)	4.0 GB/s (PCIex16)

G80 more details from R600

R600 came out finally. But, only a middle-end one can be ordered now. The reviews (1, 2, and etc.) didn't show much advantages over NVIDIA's G80. NVIDIA also came out a FUD presentation. It is quite interesting to read the presentation and it reveals more details of G80 and R600.

1. G80 has one special function unit per ALU, which is never documented or showed in any presentation from NVIDIA and manuals of CUDA.
2. R600 is a super-scalar VLIW architecture, which is different from R580 design and uses 5 scalar units instead of 1 vector unit and 1 scalar unit. That is an evolution step to the architectures used in GPU. The analysis on super-scalar VLIW architecture is fair to claim the efficiency issue. But, G80 is not a true scalar architecture, it's still kind of vector processor and also efficiency issue (and, yes, from somewhat different perspectives.) But, with compiler improvement, R600 will have more advantages if latency is critical to the computation.
3. It is reported that R600 is a cache heavy design, most of die size is devoted to SRAM. Beside texture cache and vertex cache, R600 has additional read/write cache to virtualize registers. This will benefit GPGPU (depending on the configuration of that read/write cache.) If such a read/write cache is "real" cache, that will improve the programmability and performance of R600 compared to CUDA on G80. The ever increasing complexity of graphics workload and GPGPU popularity has created demands on memory hierarchy for GPU. R600 may be optimized for stream computing.
   

CentOS5 with Acrobat Reader

CentOS5 distribution comes with gtk-2.10. It seems that Acrobat Reader package from adobe.com has problem to handle that. It is due to the function to retrieve the version of gtk. The following patch will get it solved.

--- acroread.orig       2007-04-17 16:47:25.000000000 +0800
+++ acroread    2007-04-17 16:47:55.000000000 +0800
@@ -415,7 +415,7 @@
            return 1 
         fi
 
-               echo $mfile| sed 's/libgtk-x11-\([0-9]*\).0.so.0.\([0-9]\)00.\([0-9]*\)\|\(.*\)/\1\2\3/g'
+               echo $mfile| sed 's/libgtk-x11-\([0-9]*\).0.so.0.\([0-9]*\)00.\([0-9]*\)\|\(.*\)/\1\2\3/g'
         return 0
     fi
 

new R600 photos

VR-Zone posted the new photos of R600-based X2900 XTX. It is very different from the previous photos. Definitely, the previous ones should be the engineering boards. The new one is much shorter and should be the same length as NVIDIA's G8800 GTX. More photos and schematic are also posted on the forum of VR-Zone.

The only question I want to know is when this monster will be available, the exact date.