text:
I love the .NET Framework, C# and IntelliSense, but a lot of people are still saying it's slower than C++, pointing out that video games and "major applications" are still written in C++. Naysayers often point out that apps like Office, Internet Explorer, and Windows Media Player are still written in C++, apparently implying that C++ is still the best choice for performance. But wait, isn't this mainly because those applications are older than the .NET Framework itself, or because the .NET Framework has lousy support for DirectShow, or less-than-ideal support for Direct3D?
Well, I've been using C# for years and rarely had any complaint about its performance--that is, until I wrote a program for a Pocket PC and was shocked to discover that it required 35 seconds to start up.
With this article, I am attempting to make a fair comparison between the performance of C# and C++ (unmanaged), in both desktop and mobile (Windows CE) scenarios. In the first version of this article, I wrote most of the code in C# first, and manually ported it, line-by-line, to C++, replacing standard .NET classes with STL equivalents (some of the code was ported in the other direction). Because this is labor-intensive, however, the variety and scope of those benchmarks were limited. For this updated version, I added three extra cross-language benchmarks written by two different people, plus a variation on the hashtable benchmark using sorted maps.
My main goal is to measure the performance difference in the compiler/JIT and parts of the standard library that are used most often. I'm largely limiting my tests to the C++ standard library anyway, so there's no way we can compare the speed of things like XML parsing or JPG loading, which the .NET Framework BCL can do but the C++ standard libraries cannot. No, my benchmarks will be limited to the following areas:
The original article compiled the code in Visual Studio 2008; beside those results I have added results for Visual Studio 2010 (including .NET 4) and Mono, so you can see the difference. Microsoft dropped support for Windows CE in VS 2010, which is the reason I used VS 2008 in the first place. Of course, I welcome readers to try compiling the code with other compilers or platforms (such as GCC or Windows Phone 7). Be aware that any differences you observe may be caused by using a different processor as well as a different compiler.
My test workstation is a Quad-core 64-bit Intel Q9500 @ 2.83 GHz (but all tests are single-threaded) on Windows 7. The mobile device is a Mentor Ranger 4 with a 600MHz ARM processor, and .NET Compact Framework 3.5.
Numerous individuals gave the original version of this article a "1" vote. Most of them were either unwilling or unable to state specifically why I deserved the lowest possible score, but let me address some of the specific criticisms. My sincere thanks goes out to those people who found imperfections but didn't punish me for it!
Some non-1-voters suggested that ifstream should be avoided in C++ due to its poor performance, and a poor design that prevents high performance. Given the results, they were clearly correct! For this benchmark I added FILE* tests (not direct Win32 API calls, since I prefer portable code.)
There were some other 1-vote criticisms which I couldn't possibly use to improve the article, e.g.:
Here's hoping for a more reasonable discussion this time around.
Before I start, I should mention that there's no easy way to match up garbage collections with benchmarks, so I do a GC before every C# benchmark, and I do not attempt to include that GC time in the totals. I would have liked to print out total GC time at the end, but apparently it is not possible. There is no property or performance counter for total GC time; there is an "instantaneous" measurement for "% GC time" but no obvious way to aggregate it over time. I could disable inter-test GCs, but then some GC time would be misattributed to incorrect places. I could add forced-GC time to the measured time of each test, but that would artificially inflate the C# time numbers (since forced gen-2 collections waste time compared to "natural" GCs). However, GC time shouldn't matter much here, because most of these benchmarks do not allocate a large number of heap objects (except the tests involving strings and SortedDictionary).
It has become clear that when it comes to desktop software, the target CPU, target JIT (in C#) and compiler switches (in C++) can sometimes affect performance in a big way. So for this new version of the article, I'll be testing several different scenarios (11 in total) so you can see the difference that compiler switches make. I could test more scenarios, but the graph is getting crowded.
I also benchmarked with the "VC9 NCI x86" settings plus /Ox (Full Optimization) to see if it was significantly different from the default /O2 (Maximize speed). The difference was tiny in every benchmark, and not worth including as a separate bar on the bar charts.
A couple of people wanted to know whether Mono would be faster if the LLVM JIT (--llvm command-line switch) would be faster. I found that LLVM made no significant difference in the current version for Windows (Mono 2.10.2). Some tests ran slightly faster; the majority ran slightly slower. And there was only a small difference between the first run (when JIT occurs) and subsequent runs, indicating that JIT time is not the reason for the lack of speed increase. The difference with and without --llvm was small enough that I felt it was not worthwhile to include it in the bar charts.
I'll get to the "real" benchmarking in a minute. But first...
Some C++ developers end up distributing Debug builds so that "assert" statements continue to work, or so that they can debug the production machine if they have to. Unfortunately, this tends to kill performance, as the graph below shows
(Note: I did not update these graphs for the new article. I don't think new graphs would teach us anything new about Debug builds.)
In this graph, the scale has been adjusted so that the x86 Release build takes one unit of time. Some operations, most notably function calls and anything involving STL, are dramatically slower in desktop Debug builds. I suspect "Generic sum" is so much slower mainly because the STL vector it scans is slower; and you may find that hash_map is virtually unusable in a debug build, as you'll see.
When I first ran the x86 Debug benchmark, I noticed that it seemed to be "hung". I stopped it in the debugger and found it was running the "string hash_map: 1 Adding items" test. This test fills the hashtable with 2.5 million items, clears the list, and fills it again three more times. Well, when inserting the first item after a clear() command, hash_map gets stuck doing who-knows-what for around 4 minutes, for a total runtime of 16 minutes and 20 seconds (78 times longer than the Release build). I left it running overnight, and discovered that the removal test is even worse. This test tries to remove 10 million items, but the list size is limited to 2.5 million so most of those requests fail. For whatever reason, this test took 10 hours and 37 minutes, which is 9400 times longer than the Release build!
This turned out to be caused by the Visual C++ "iterator debugging" mis-feature. #define _HAS_ITERATOR_DEBUGGING 0 makes it realistically possible to run the benchmark, but the hashtable tests are still extremely slow in debug builds.
#define _HAS_ITERATOR_DEBUGGING 0
This graph also shows that the same piece of code can run at many different speeds depending on your platform and compiler settings. For example, some tasks, especially those involving 64-bit integers (or to a lesser extent, floating point), run faster when targeting x64. Once in awhile, x64 handles a task more slowly (for some reason, reading a file with ifstream::read() is much slower in 64-bit).
The C# results are more consistent:
In fact, only a few operations are significantly slower in a C# Debug build compared to a Release build. One reason for this is that the .NET standard library, known as the BCL (Base Class Library), is optimized even when you are running a Debug build. This explains why the speed of the Dictionary<K,V>, file and string parsing tests (which mainly stress the BCL) are almost the same in Debug and Release builds. Additional optimizations seem to be enabled when C# Debug builds run outside the debugger, as these benchmarks did. In fact, the C# x86 Debug build outperformed the C++ x86 Debug build in all tests except two.
But of course, what we really care about is Release builds. The rest of this article will examine Release builds only (using Visual Studio's default compiler settings).
To add more "realism" to my benchmark, I incorporated three benchmarks from two other people. I refactored their code slightly, to make the code fit better into my benchmarking framework and (in two benchmarks) to improve the C# version by eliminating 2-dimensional arrays, because performance-sensitive C# code should avoid them. I did not have time to prepare ARM bar charts for these new tests (or any other tests, for that matter).
The first two benchmarks I added were written by a Mr. Attractive Chaos. There are actually 4 benchmarks in his test, but one tests dictionaries, and I already have a benchmark for that, and one tests a particular C RegEx library, whereas I'd prefer to stick with standard libraries here. The first benchmark I kept is a straightforward O(n^3) matrix multiplication, and the second is a high-quality but (to me) hard-to-follow Sudoku solver. Then again, I've never played Sudoku.
Both benchmarks were originally written to use 2-dimensional arrays in C#. Now, writing about the matrix test, the author stated: "this is the first time I write C#". More seasoned C# developers have learned that .NET's multidimensional arrays are no good for performance. They weren't designed to be fast. Instead, it may be better to simulate 2D arrays using either with 1D arrays or "jagged" 2D arrays (double[][] instead of double[,]). The easiest way to eliminate a multidimensional array from your code is to introduce a wrapper such as this:
public struct Array2D<T> // use "class" if you prefer { readonly T[] _a; readonly int _cols, _rows; public Array2D(int rows, int cols) { _a = new T[rows * cols]; _cols = cols; _rows = rows; } public Array2D(T[] array, int cols) { _a = array; _cols = cols; _rows = _a.Length / cols; } public T[] InternalArray { get { return _a; } } public int Cols { get { return _cols; } } public int Rows { get { return _rows; } } // Add a range check on "col" if you want to sacrifice performance for safety public T this[int row, int col] { get { return _a[row * _cols + col]; } set { _a[row * _cols + col] = value; } } };
In some conditions, the wrapper will be much faster than a standard .NET 2-dimensional array (type[n,n]), but as the benchmark will show, this is no longer a reliable optimization, and you'll often get better results from a jagged array.
In this benchmark, two monster 1000x1000 matrixes are multiplied. The C-style multiplication routine is straightforward and hopefully uncontroversial; the inner loop is optimized with "a_i" and "c_j" to avoid unnecessary multiplications, and the "b" matrix is transposed so it can be accessed sequentially. The original version could multiply only square matrixes, but I took the liberty of extending it to handle rectangular ones (untested, mind you).
double* MultiplyMatrix(double* a, double* b, int aRows, int aCols, int bCols) { // int m = aRows, n = bCols, p = aCols; // Note: as is conventional in C#/C/C++, a and b are in row-major order. // Note: bRows (the number of rows in b) must equal aCols. int bRows = aCols; double* x = new double[aRows * bCols]; // result double* c = new double[bRows * bCols]; for (int i = 0; i < aCols; ++i) // transpose (large-matrix optimization) for (int j = 0; j < bCols; ++j) c[j*bRows + i] = b[i*bCols + j]; for (int i = 0; i < aRows; ++i) { double* a_i = &a[i*aCols]; for (int j = 0; j < bCols; ++j) { double* c_j = &c[j*bRows]; double s = 0.0; for (int k = 0; k < aCols; ++k) s += a_i[k] * c_j[k]; x[i*bCols + j] = s; } } delete[] c; return x; }
In C# there are various ways the same task could be accomplished. The original version used a multidimensional array (double[n,n]); I added three more methods, in increasing order by speed:
The method you choose makes a big difference:
As you can see, the version based on pointer arithmetic (double[n*n]) is the fastest, and the jagged (double[n][n]) version is just barely slower.
When you look at x86 results (ignoring Mono), double[,] is clearly the slowest at about 5.8 seconds. Array2D is nearly twice as fast at 3.2 seconds. And double[n][n] is twice as fast again, at 1.6 seconds. However, the x64 results are downright weird. Evidently Microsoft optimized multidimensional arrays for x64, so they are even faster than Array2D. At the same time, there is a "glitch" in x64/.NET4 that makes Array2D slow on that specific version of the JIT.
Note: from now on when I refer to "x86", I'm excluding Mono unless otherwise noted. Mono isn't doing very well so far, and it will continue to do poorly for a lot of these tests. In fact, originally I used a dark gray color for Mono. But those extremely long Mono bars were becoming a distraction, so I changed it to light gray. Like I said, if you don't use Mono, just ignore those long gray bars. If you do use Mono, well, you see that Array2D bar that goes right off the end of the chart? It's 11.75 seconds.
The one constant is that the jagged array is faster than the multidimensional array. I haven't figured out how to look at the assembly to see what's going on yet, but I can think of three reasons why the jagged array would be faster. First, .NET does range checks on all array accesses, except inside a for-loop that iterates from 0 to the end of the array, which the jagged implementation is (mostly) able to do. Second, when using a 2D array, a JIT that is not smart will fail to factor out the multiplication from the inner loop. Third, even if it does factor out the multiplication, it may fail to precompute a pointer to the part of the array being examined (indeed, the GC may make it hard to do that). In contrast, the jagged version needs no multiplications, and we can explicitly cache a reference to the current row of the matrix, like the C++ version does.
The version that uses pointers may avoid a single additional range check in the inner loop, so it should be slightly faster.
This whole discussion points to a general problem with C# performance compared to C++: .NET JITs aren't as good at optimization as C++ compilers. This is natural, because JITs execute at run-time so they can't optimize as aggressively (for fear that the program will start too slowly). In the future one could imagine smarter JITs that produce a slow version of the code and then (after a loop has executed several thousand times) take a time-out to optimize the code as well as a C++ compiler. They already have that kind of optimization technique for interface dispatch. But for everything else? No.
So, if you need fast C# code, you may have to optimize it yourself: manually factor out expressions from the inner loop, switch to jagged arrays, or even introduce pointers. Manual optimization can be a huge pain though, as in this case where the inner-loop multiplication is hidden inside a call to the indexer. So instead you could try NGEN, the results of which have not been included in this article. Maybe next time.
Now, the main matrix multiply test uses double arithmetic, but not all programmers are concerned primarily with the speed of double arithmetic. Therefore, I also wrote generic versions of the tests, so you could see the effect of different data types, specifically int and float.
In the first version of this article I tested C# generics to see if the JIT could optimize them as well as a C++ compiler optimizes templates. The results seemed to say yes, but the test was very simple. For this extension of the matrix multiplication test I compared two data types (double and int) with 5 different JIT engines, and in several cases the JIT botches the job. Have a look (<angle brackets> represent generics):
(Note: I threw in a generic float test so you can compare with the C++ float test, but I was too lazy to manually write its non-generic version.)
When you look at the results for x86 using integers, they are fine: generic <int> is exactly the same speed as non-generic int. However, if you look at the results for x64/.NET3, you'll see that the generic double test takes 2.14x longer, and the generic int test takes 3.45x longer. The .NET 4 JIT isn't so bad, but it flubs the integer test a little. And Mono seriously bombs the generic tests, especially involving floating point (the result is 9.7 seconds for <double>, and 11.3 seconds for <float>.)
C++, on the other hand, reveals absolutely no difference between the template <double> version and the original non-template version:
Notice that the bars for double[n*n] and <double>[n*n] are exactly the same. The C++ compiler evaluates templates at compile-time using token substitution, so there is no reason to expect any difference. Therefore, I didn't bother with a non-template int or float version; the numbers are just there so you can compare them with C# if you want.
Note: for the generic tests I eliminated fractional numbers from the matrix in case the data type is "int". Integer overflows do occur during the multiplication, but hopefully this does not mess up the results.
Setting aside the issue of generics, and avoiding those unpredictable 2D arrays, let's see how C# compares with C++. This chart shows the original C++ version and its direct C# equivalent, plus the [n][n] version which is more appropriate in C#:
The results are clear. First of all, C++ wins in every case. If you use the x86 JIT, C# is only a little slower than C++. But the x64 and Mono JITs perform quite poorly on this test. Note that the jagged array version (double[n][n]) is the most reasonable way to do large-matrix multiplication in C#, because pointer arithmetic is frowned upon in C# culture. You only loose a little speed by using jagged-array version instead of the pointer arithmetic version, but the memory cost (16B per row and slower GCs) should be kept in mind.
The code of this, the second benchmark by Attractive Chaos, is too long to post here. Basically, it involves a lot of array accesses, if-statements and loops, but very little arithmetic and no floating-point. Thus, this test stresses a compiler/JIT's ability to optimize array access, register allocation, and flow control.
This test uses numerous one-dimensional arrays and two two-dimensional arrays. As before, I switched the C# 2D arrays with Array2D wrappers, which increased x86 C# speed from 6 seconds to 5.2 seconds, but might have hurt the x64 speed (I didn't check). here are the results:
In theory, C++ should have an edge in this test because it uses arrays heavily, and it does not simply scan arrays from beginning to end like the Matrix test does. In cases like this, .NET inserts a range check for all array accesses. Also, C++ supports only fixed-size minor array dimensions, while C# supports only dynamic minor array dimensions, so, for example, .NET can't optimize the code on the knowledge that the array called "C" is always 16 bytes per row.
Anyway, VC++ wins big this time, typically running twice as fast as .NET, if not more (and Mono brings up the rear again, at 8.6 seconds). My experience suggests that array range checks can't account for such a big difference, but investigation is hindered because I still don't know how to look at C#'s optimized assembly. Go ahead and laugh at me. Ha!
The third benchmark is by A.D. Corlan. It's a very simple test which computes the value of a 100-degree polynomial using float math.
The first time I ran this "Polynomials" benchmark in C# and C++ (VS 2008, x86), the result was that C++ finished in 0.034 seconds, and C# in 7.085 seconds, making C++ was 208 times faster! Of course, other than the C++ DEBUG hash_map test that took over 10 hours, this was the most extreme result I had ever seen. The C++ result seemed impossible: the outer loop does 10 million iterations and the two inner loops do 100 iterations each, for a total of 2 billion iterations. There was no way so much work could be done in 0.034 seconds on a 2.83 GHz processor. Indeed, looking at the assembly of the outer loop, you can see that the compiler had done something amazing:
for(int i=0; i<Iterations; i++) pu += dopoly(x); 00CCB740 push ecx 00CCB741 fld dword ptr [__real@3e4ccccd (0CD2D54h)] 00CCB747 mov dword ptr [esp+40h],0 00CCB74F fstp dword ptr [esp] 00CCB752 call Polynomials::dopoly (0CCB650h) 00CCB757 fstp dword ptr [esp+40h] 00CCB75B fld dword ptr [esp+40h] 00CCB75F add esp,4 00CCB762 mov eax,989680h 00CCB767 sub eax,1 00CCB76A fld st(0) 00CCB76C fadd dword ptr [esp+38h] 00CCB770 fstp dword ptr [esp+38h] 00CCB774 jne Polynomials::Test+37h (0CCB767h)
Notice that jne branches to 0x0CCB767, which is after the call to Polynomials::dopoly; the function is called only once! The C++ optimizer somehow figured out that dopoly() is functional--that is, it always returns the same result given the same input--so it factored out the function call from the loop!
While I am truly impressed with the optimizer's cleverness, this just won't do for a benchmark. The idea was to figure out how long 10 million calls to dopoly() would take, not just one call. So I made a small change: there is an array declared on the stack inside dopoly(). If I move that array to the calling function instead, and pass it in as a parameter, the optimizer no longer believes it can factor out dopoly(), so it is called 10 million times as desired. This change increases running time by a factor of 289, from 0.034 seconds to 9.813 seconds.
Anyway, here's the graph:
The average C++ SSE2 version completes in about 24% less time than the average C# version (ignoring Mono's sad 13 seconds.) The C++ x87 version, though, is pretty slow. While I was investigating the "clever optimizer" issue above, I think I saw the reason why. I'm no x87 expert, but look at this. The compiler unrolled the second loop of dopoly() 10 times, but the unrolled loop looks like this:
for (j=0; j<100; j++) s = x*s + pol[j]; 000DB696 fld dword ptr [esp] 000DB699 add eax,28h 000DB69C sub ecx,1 000DB69F fmul st,st(1) 000DB6A1 fadd dword ptr [eax-30h] 000DB6A4 fstp dword ptr [esp] 000DB6A7 fld dword ptr [esp] 000DB6AA fmul st,st(1) 000DB6AC fadd dword ptr [eax-2Ch] 000DB6AF fstp dword ptr [esp] 000DB6B2 fld dword ptr [esp] 000DB6B5 fmul st,st(1) 000DB6B7 fadd dword ptr [eax-28h] 000DB6BA fstp dword ptr [esp] 000DB6BD fld dword ptr [esp] 000DB6C0 fmul st,st(1) 000DB6C2 fadd dword ptr [eax-24h] 000DB6C5 fstp dword ptr [esp] ...
It's repeatedly storing and loading the loop variable, s. Oops!
This test pits two types of .NET Dictionary against the equivalent Microsoft C++ hash_maps (or unordered_map in VS2010). First I tried an <int, int> hashtable, then a <string, string> hashtable.
<int, int>
<string, string>
The string tests use the same keys as the integer tests, but converted to strings. Each test converts 10 million integers to strings (which is all that test "0" does), so you may want to mentally subtract test "0" from all the others.
The results may surprise you:
With an occasional exception, C# wins by a landslide! One particular C++ scenario, x86 VC10 with SSE2, runs better than the others and when handling strings, outperforms C#. However, in most situations VC++ loses big time. The first test, for example, runs over 9 times faster in .NET4 x64 compared to C++ VC10 SSE2.
Why is the difference so large? Well, I suspect Microsoft's (Dinkumware) hash_map is simply terrible. I don't know how it's implemented; the code is so ugly I can't stand to even look at it. Honestly, who indents code like this?
// TEMPLATE CLASS _Hash template<class _Traits> class _Hash : public _Traits // traits serves as base class { // hash table -- list with vector of iterators for quick access public: typedef _Hash<_Traits> _Myt; typedef typename _Traits::_Val_type _Val_type; typedef typename _Traits::key_type key_type; typedef typename _Traits::key_compare key_compare; typedef typename _Traits::value_compare value_compare; enum { // various constants _Bucket_size = key_compare::bucket_size, _Min_buckets = 8, // min_buckets = 2 ^^ N, 0 < N _Multi = _Traits::_Multi}; typedef list<typename _Traits::value_type, typename _Traits::allocator_type> _Mylist;
At least they added some comments to the VS 2010 version.
Anyway, I can say with certainty that it's not the C++ compiler's fault. I know this because I wrote my own version of hash_map for my company, and my implementation runs roughly ten times faster (with int keys). I knew I got better performance from my hashtable, but I didn't realize how dramatic the difference could be until I saw the numbers. Here are the results based on my implementation:
As you can see, C++ is much more competitive now. It wins some races, and loses others. My hash_map is heavily inspired by the design of .NET's Dictionary, and I am unable to guess why my version outperformed C# while doing int queries and removals, yet not inserts.
When it comes to strings, it is worth noticing first of all that they are dramatically slower than integers, regardless of the programming language you use, and for longtime programmers this will come as no surprise. I believe C++ is at a fundamental disadvantage whenever strings are stored in collections. The reason is that C# uses immutable strings, and no work is required to construct or destruct a "copy" of a string. The C++ STL, however, uses mutable strings, which require extra work to copy a string--depending on how std::string is designed, either bookkeeping is required to track how many std::strings point to the same string (this approach makes modifying a string more expensive), or the entire string must be copied (so changing a string is cheaper, but copying is more expensive). In any case, when adding a string like "12345" to the hashtable, some work must be done to make a copy.
On the other hand, the STL does have a slight performance advantage, in that its template classes are specialized and optimized for every specific data type at compile-time. Thus, the compiler can specifically optimize hash_map<string,string> for strings. In contrast, the .NET Framework specializes generics at run-time if they are based on value types (such as Dictionary<int,int>) but not if they are based on reference types (such as Dictionary<string,string>). Thus, there is a slight overhead when the .NET hashtable calls string.GetHashCode and string.Equals. In general I believe the C# design is a better balance, since it avoids code bloat--some types of Dictionaries can share the same machine language code--while still offering higher performance for simple types like "int" and user-defined structures.
Finally, let's see how the Compact Framework performed against VC++ for ARM:
Yikes! In the integer case, the hashtable queries and removals are over 3 times faster in C++, although insertion is still mysteriously slower. The string tests are where things get bad, and somehow I am not surprised. The .NETCF program I mentioned at the start, the one that needed 35 seconds to start, was busy parsing strings and adding them to a list. String test 1 runs 3.5x slower in C#; test 2 is 9.1x slower; and test 3 is 7 times slower.
Disclaimer: the above tests use sequential integer keys. Therefore the hashtables enjoy virtually no collisions, which means that these test results are probably better than real-world results.
Someone pointed out that map<K,V> is more commonly used in C++ than hash_map<K,V>. That's true, because for the longest time C++ didn't offer a hashtable. Now in theory a hashtable should be faster, because it should support O(1) constant-time operations, in contrast to a map which is sorted and necessarily requires O(log N)-time operations.
Strangely, however, the MS STL's map<K,V> is actually faster than its hashtable (hash_map or unordered_map), although not as fast as my hash_map. In the .NET world, SortedDictionary is slower than Dictionary as you would expect... but does it have to be this much slower?
C++ wins by a landslide! C++'s map<K,V> is quite fast, while C#'s SortedDictionary<K,V> is quite slow. Now, I've partly developed a C# B+tree, which may end up being faster than SortedDictionary; leave a comment if interested (I suspect nothing helps me write code like peer pressure!)
C++ is still widely used for numerical applications--apps in which most of the time is spent in the application code, not the standard library or waiting on I/O--because its compilers are considered very good at optimization. As a bonus, C++ template programming lets you write a numerical algorithm that supports multiple numeric data types.
The generic sum test in C# is based on an enhanced version of a library written in 2004 by Rüdiger Klaehn, which observes that with some extra developer effort, it should be possible (although not especially easy) to write and use C# generics to write fast math code that supports arbitrary number types.
Earlier in this article I talked about the generic version of the matrix multiplication benchmark and the fact that C# doesn't always optimize generics as well as you'd hope. I actually wrote this sum benchmark for the original version of this article, and it may seem a little redundant in version 2, but there are still some interesting observations we can make. For instance, I'm testing fixed-point structures here, which I rely on heavily in my C++ ARM code.
In addition to int, int64, float and double, I tested with FPI8 and FPL16. These are fixed-point data types that I created myself. Many, if not most, mobile devices have poor floating-point support, so I often use fixed-point instead of floating-point on such devices. A fixed-point type in C++ or C# is simply a struct with an integer inside it (FPI8 contains an int, FPL16 contains a 64-bit int). Some of the low bits are treated as fractional. The "8" in FPI8 means there are 8 fraction bits, so FPI8 can store numbers between -16777216 and 16777215.996, with a resolution of about 0.004. The fact that a "struct" is involved is an important part of the benchmark: historically, compilers could not handle a structure that contains a single value as well as that value by itself (outside the structure), but these days most compilers do a good job.
I tested the following generic C# sum method:
public static T GenericSum<T, Math>(List<T> list, Math M) where Math : IMath<T> { T sum = M.Zero; for (int i = 0; i < list.Count; i++) sum = M.Add(sum, list[i]); return sum; }
Of course, in C++ the natural implementation is simpler:
template<typename T> T GenericSum(const vector<T>& list) { T sum = (T)0; for(int i = 0; i < (int)list.size(); i++) sum += list[i]; return sum; }
However, many C++ template libraries (Boost::GIL comes to mind) rely heavily on the compiler to inline tiny functions and eliminate empty structures, so at first I directly ported the convoluted C# code to C++ with the confidence that the compiler would make it fast. However, in an effort to avoid future hooliganism from certain 1-voters, I changed the code to what you see above (although I had to eliminate a virtual-function test as a side-effect). There are still two function calls there that the 1-voters probably didn't think twice about. You could eliminate them by using raw arrays instead of the STL, but why bother? The compiler does optimize it. Let it do its job.
Because adding a number is such simple work, I did 10x as many iterations for this test as for most others. For reference, I also included a non-generic integer-summing method in both languages. Here are the desktop results:
Note: I'll give the ARM results down below.
Note: I just noticed that I forgot to do this test with FPI16. Sorry, I don't have time to re-run all 11 benchmarks.
Funny story. While I was preparing version 2 of this article, I noticed something weird about all the C++ Generic Sum test results: they were all 0.000! WTF? In the debugger, it became clear that the optimizer had completely eliminated the loop that called GenericSum()! This was a reasonable thing for the optimizer to do, because the outer loop ignored the return value. But the puzzle was, why did the optimizer's behavior change? One of my tests, the non-generic sum test (which operates on vector<int> instead of <T>), had not been changed. I downloaded the old code and checked to be sure. No, the non-generic sum code was exactly the same as before, but now it ran in zero time. What had changed? I was using the same compiler (VC9). I checked all the compiler switches--identical! At that point I literally gave up and went home.
The next morning it occurred to me. Checked iterators! I had disabled them, but I had not noticed for several days that my GenericSum results were zero. Why not? Well, the benchmarks were run in random order, but I failed to randomize the random number seed. As luck would have it, the first GenericSum test came quite late among the benchmarks and, apparently, I just never ran the program long enough to see the results!
Anyway, somehow, disabling checked iterators enabled the optimizer to delete my benchmark completely. To fix this, I changed the outer loop to compute the sum of all sums and return it, so that the optimizer couldn't be so aggressive. Then I had a new "problem": the benchmark ran incredibly fast, less than 0.05 seconds for 100 million additions. What was that about? I checked the assembly. This time the results turned out to be legitimate. Disabling checked iterators more than doubled the speed of this benchmark.
By disabling checked iterators, you eliminate the range check on vector accesses. Apparently, this lets the optimizer be more agressive and the test runs really, really fast. Thus, provided checked iterators are off, the C++ version totally blows away C#. However, if you look at the "C++ x86 VC9 default" bar, you'll see what happens if you don't turn them off. In that case, some of the C# tests aren't that much worse than C++.
Something to notice about the C# results is that they are highly variable. The Microsoft x86 JITs don't do too badly, provided that you are adding up integers or FPI8 structures; but as soon as you try double, all 5 of the JITs suck. The x64 .NET3 JIT is especially bad for all data types, and both x64 JITs do worse than their x86 counterparts. And, for some reason, Mono bombs every test including the non-generic one. Hmm, I suspect Mono has some trouble optimizing code that involves structures, since all generic math relies on a special "Math" structure, and it handles the FPI8 structure much worse than plain "int" (the Mono FPI8 test, which overflows the chart range, takes 1.57 seconds.).
Although C++ wins this test by a wide margin, it should be noted that most of the C++ tests are executed with no range check on the array accesses, while the C# tests are run with a range check. I did a quick test to see what happens if NonGenericSum is written to use int[] instead of List<int>:
In this case .NET optimizes out the range check, and C# runs more than twice as fast (more than four times as fast in x64!) and not much slower than the C++ version. However, it should be noted that in real life you can't always use an array instead of List<T>, nor can you always loop through the entire array, and when you don't, .NET won't optimize out the range check. The only other way to eliminate the range check is to rewrite the code to access the array through a pointer.
In C++ it's much more convenient, since you can use the STL and just #define _SECURE_SCL 0; however, this also carries a disadvantage that range checks are disabled throughout the entire program (note that it's not legal to change _SECURE_SCL per-cpp-file, which would violate the One Definition Rule). Hey Microsoft, if you're listening, you could solve this problem in C# with a special intrinsic to perform the range-check explicitly before the loop:
#define _SECURE_SCL 0
Array.RangeCheck(array1, a, b); // JIT would see this as an optimization directive Array.RangeCheck(array2, a, b); for (int i = a; i < b; i++) array1[i] = array2[i]; // No range checks for (int i = b-1; i >= a; i--) ... // No range checks in a reverse loop either
Combined with a smart optimizer and a List<T>.RangeCheck(), List<T> could achieve high speeds too. And that's for verifiable code; within "unsafe" methods, a special attribute could disable all range checks. Of course, MS is probably not listening to me. But if you are, I demand to know why MS .NET still lacks SIMD structures! (VC++ has them, although they are foolishly processor-specific.) But I digress...
The "Simple arithmetic" test, admittedly, was a little too simple; two compilers of generally similar quality may optimize small pieces of code differently, so you shouldn't trust these results too much. This is what I did for each numeric type:
double total = 0; for (int i = 0; i < Iterations; i++) total = total - total / 4.0 + (double)i % 100000 * 3.0;
Part of this test is to see whether the compilers can optimize multiplication and modulus by a constant. Here are the desktop results:
There's no clear winner for this test. Generally, C# did a better job in the "double" test (even when C++ is allowed to use SSE2), but a worse job in the FPL8 and FPL16 tests. C# is tied with C++ in the float test, until you enable SSE which causes C++ to win. In the int64 and FPL16 tests, the instruction set (x64 or x86) has a larger effect than the programming language. And then there's Mono. When it comes to handling int64 or the FPI8/FPI16 structures, it does pretty badly, but in the double test it does better than everybody else. What gives, Mono?
public static uint Sqrt(uint value) { if (value == 0) return 0; uint g = 0; int bshft = Log2Floor(value) >> 1; uint b = 1u << bshft; do { uint temp = (g + g + b) << bshft; if (value >= temp) { g += b; value -= temp; } b >>= 1; } while (bshft-- > 0); return g; }
It's a pretty typical mix of arithmetic and flow control. For reference, I've included the standard double square root (for which x87 and SSE2 offer specialized instructions). Here are the desktop results:
C++ wins this test, but not by a wide margin (unless you count Mono). In the 64-bit tests, the instruction set (x86 or x64) matters more than the programming language.
Notice that "Square root: FPL16" is slower than uint64 (ulong), in both C++ and C#. The reason for this is not that ulong is wrapped in a FPL16 structure. Rather, the reason is that FPL16 has 16 fraction bits and uint64 has none, so the square root algorithm (which operates on a raw uint64) requires more iterations to compute the square root.
Unfortunately for me, the Compact Framework performs dramatically worse in all three arithmetic tests.
For this graph I added ratio-bars to the right side, so you can see just how badly the CF is doing (not easy; I had to work around a bug in Excel.)
In fact, C++ beats the Compact Framework by a huge margin on most of these tests. The "best" results (where .NETCF is only slightly slower) involve the double floating point type, but this is only because most of the time is spent in the system floating-point emulation library, regardless of your programming language. This is a huge disappointment; it suggests that the Compact Framework is incapable of doing math or algorithms quickly, and the results are even worse when using FPI8 or FPL16. Plus, it might not optimize generics very well; notice that the C# "int (non-generic)" test is faster than the "int" (generic) test.
In this test I try out two different ways of reading a 400KB text file with about 17000 lines: either by reading the entire file at once into a buffer, or by reading it line-by-line. The file has been loaded before so that it is in the disk cache. This benchmark does not measure disk performance, nor do I want it to.
In C++ I originally used a std::ifstream, but it turned out that ifstream is slow, so I've added good old FILE* as an alternative in this second edition of the benchmark. In C#, I used System.IO.File wrapped in a StreamReader.
The text file contains "dictionary entries": key-value pairs separated by ":=". The value can span multiple lines; if a line does not contain := then it is assumed to be a continuation of the value on the previous line. The dictionary entries are collected into a C# List or C++ vector, then randomized a bit (to ensure sorting requires some work) and sorted by key in a case-insensitive manner. First, let's see how fast the two languages can read text files:
The "x20" indicates that the file is scanned 20 times, just to eat up time on the clock.
Clearly, C++ ifstream does a terrible job at reading lines from the file one-by-one. So instead let's just sweep that under the rug, and pay attention only to the FILE* result. By the way, VC10 and x64 do this task better than VC9 x86. SSE2 optimizations don't get the credit, since x86 VC9 with SSE2 enjoys no improvement.
Evidently, C++ is faster than C# if you read the whole file as one block. This makes sense, because .NET actually has to do more work in these tests: it is decoding UTF-8 to UTF-16. Standard C++, in contrast, doesn't support conversion between text encodings, and these tests use "char" strings (not wchar_t), so the only extra work C++ has to do is to convert line endings (\r\n to \n), work which C# does too.
It is therefore peculiar that C# wins the second test, reading line-by-line (ReadLine() in C# vs getline() or fgets() in C++). It occurs to me I could have optimized the FILE* version better; for example, fgets() does not return the string length. So, to eliminate the '\n' at the end of the string (necessary to make the code's behavior equivalent to the other two versions), I call strlen() to get the string length, then change the last character to '\0'. It might have been faster to convert to std::string first (which determines the string length) and then remove the last character.
Anyway, let's see the results for parsing and sorting:
Like any clever C++ coder, I optimized tests 2 and 3 by adding empty strings to the end of the vector, and then creating the strings in-place so that it is not necessary to copy them into the vector. Even so, C# is quite competitive in those tests. The winner of the "Parse" test (which involves calling IndexOf, Substring and the C++ equivalents in std::string) depends on the platform (x86 or x64). The one place where C++ definitely wins is during the case-insensitive string sort (std::sort vs List.Sort). I wonder whether the C#'s ability to sort Unicode (É < õ), which _stricmp presumably cannot do, has something to do with this result.
If anyone's keeping score, Mono takes 5.666 seconds to sort the strings.
The Compact Framework may perform better than ifstream:
But again, compared to C++, the parse test takes 8 times longer in the Compact Framework, and the sorting test takes a whopping 15 times longer. It would have been nice to look at the disassembly to see why it's so slow, but the debugger reports that disassembly is not supported in the Compact Framework.
After seeing the dismal results of the Compact Framework tests, the question came up: what if some of the code were written in C++ and called from C#? This could compensate for some of the slowness of the Compact Framework. If you use P/Invoke a lot, though, it's important to consider how long it takes to cross the boundary between C# and C++.
I tested P/Invoke performance by calling a very simple DLL that I made myself. The functions in that DLL do something trivially simple, such as adding two numbers or returning the first character of a string. Below you can see both .NET desktop and Compact frameworks.
As my tests show, crossing that boundary isn't what I'd call cheap, even if the arguments and return values are simple integers.
On my workstation, you can call Add(int,int) about 25 million times per second in the x86 and x64 versions of .NET (112 cycles per call at 2.83 GHz). Mono is more than twice as fast (45 cycles), and the Compact Framework manages 2.74 million calls per second (219 cycles per call at 600 MHz). Now, these results are not terrible. But non-P/Invoke calls are much faster, as you'll see below.
Passing strings or structures makes P/Invoke calls much slower in some cases (but not all cases). If the C++ method returns a string then .NET must convert it to a System.String, which of course takes extra time. If the C++ string has type char*, then additionally a type conversion occurs; but since .NET does not support UTF-8 conversion, this conversion is probably a simple truncation from 2 bytes to 1 byte (or expanding 1 bytes to 2 bytes on return). However, you can pass strings to C++ very fast using wchar_t*, since the string is not copied. (Note: if the C++ function modifies the string, be sure to use StringBuilder instead of string, or the immutable string will be modified, which is illegal and dangerous.)
I tested how well P/Invoke handles structures by marshaling between .NET's System.Drawing.Point structure and Win32's POINT structure. MakePoint() takes two integers and returns a Point, while GetPointY is passed a Point and returns its Y coordinate. The interesting thing about these two methods is that the x86 marshaller handles them very slowly, but all other CLR versions are fast. The MakePointIndirect() function returns a pointer to a Point (a static variable inside the function), which the C# caller must unpack using Marshal.PtrToStructure. You can see that this is very slow, too. If you want to make sure that a structure is passed or returned to C++ code quickly, be sure to pass it by reference, which the GetPointYIndirect() function does, and do not return a structure by value.
The .NET Compact Framework has some marshaling limitations:
If you have to pass floating point values or structures, you must pass them by reference, not by value. That's why I made an extra test for adding a pair of double*. Since there is an extra cost for converting a returned double* to a double, you're better off using an "out double" parameter instead of an IntPtr (i.e. double*) return value; the same guideline applies to structures.
out double
So, how much faster are normal, non-P/Invoke calls? Look how fast do-nothing NoOp() functions can be called:
You can see here that 10 million non-inlined calls take around 24 milliseconds on the desktop, as compared to about 400 milliseconds for NextInt(), a trivial C function that increments and returns a counter, or 160 milliseconds if NextInt() is called from Mono. Thus, simple P/Invoke calls are about 16 times slower than non-inlined method calls in .NET (and 18-23 times slower than virtual method calls), about 6 times slower in Mono, and 9 times slower in the Compact Framework (380 ms vs 42 ms).
This means that you can never "optimize" .NET code by using P/Invoke to call a function that does very little work. For example, if the C++ version of your code is twice as fast as the C# version, and P/Invoke uses about 110 clock cycles minimum (210 in CF), each C++ function call will have to do (on average) 110 (or 210) clock cycles of work just to "break even" with your C# speed.
And what about inlining? If a method does very little work, these results show that it will be much faster still if it is inlined. The "static no-op" test allows inlining of a static function that does nothing at all, which means that the test effectively just measures an empty for-loop. Clearly, one iteration of the for-loop is much faster than a non-inlined method call (except in the Compact Framework).
Actually, the inlined x64 version seems almost impossibly fast, at 0.001 seconds for 10 million calls. Just to be sure, I temporarily did 100 times as many loop iterations, and found that .NET x64 does one billion iterations in 89.5 milliseconds, or 11.2 billion iterations per second, which is 4 iterations per clock cycle. Maybe the x64 JIT does some fancy loop unrolling, but the debugger wouldn't let me see the assembly for some reason.
In this "trivial method calls" test I actually started by testing an Add(i, i) method (where i is the loop counter), but it turns out that the difference between Add() and a no-op is very small (2-3 ms on the desktop). In other words, the call itself is much slower than passing "int" arguments or adding the arguments together. So I got rid of the arguments, so that you can see the basic call overhead by itself, with nothing but a for-loop getting in the way.
Add(i, i)
The "no-inline" test uses the [MethodImplAttribute(MethodImplOptions.NoInlining)] attribute to ensure that a static no-op method is not inlined. Strangely, the method that uses this attribute (which is non-virtual) is consistently slower than a "virtual" no-op method in all desktop CLRs.
Only the Compact Framework agrees with the widely-believed notion that virtual functions are slower, and wow, virtual functions are really very slow on that platform! The results seem to suggest that the Compact Framework uses the same mechanism for virtual dispatch and interface dispatch, which is sad because its interface dispatch is clearly quite slow (9 million calls per second, or 66.6 cycles per call, compared with 25.2 cycles for a non-virtual no-op).
I made one more graph that you might find interesting. It's the relative performance of different implementations of the CLR. All the benchmarks are scaled so that .NET x86 uses 1 unit of time (I must scale the results somehow in order to present all the tests on the same graph.)
I am happy to report that all benchmarks ran without modification under Mono. The Mono results are only shown for x86 because the download Mono page does not offer an x64 version for Windows (or an ARM version for WinCE.)
Of course, the Compact Framework is not directly comparable as it runs on a different processor, but I included it for completeness, with 10% of the workload (I estimate from a lot of benchmarking experience that the processor itself is, at best, 1/7 as fast as my workstation for single-threaded code, or slower when running complex or memory-intensive code.)
As I mentioned before, some of the P/Invoke tests are very slow under the x86 CLR, so the time measurements for the other platforms are tiny in comparison. x64 outperforms x86 in other areas too, such as "long" arithmetic and string handling, but for some reason the "Generic sum" tests are slower under x64 and Mono, and floating-point handling seems a little slower too.
Mono does okay in general, and does P/Invoke especially well, but it falls behind Microsoft's x86 CLR in most other tests. The case-insensitive sort, FPI8 arithmetic, long arithmetic and Generic Sum tests run fairly slowly under Mono, but the hashtable (Dictionary) and Square root tests gave decent results.
The Compact Framework, of course, gave a lot of poor results. Even ignoring the floating-point tests (which use software emulation), three tests went right off the right side of the graph. For example, the Sort test took 13.0 times longer than x86, but since the mobile benchmark performs 10% as many sorts, this really means that a C# string Sort would takes 130 times longer on the mobile device than the same C# on my workstation. In fact, I suspect it was a string sorting operation that was the main cause for the 35-second startup time I mentioned at the beginning of this article. Only the P/Invoke tests, and the conversion of "Ints to strings", were relatively quick in the Compact Framework.
In this second edition of the benchmark we can make some new conclusions. The original article tested VS2008 with default optimizations, and the results seemed clear: if you're developing software for the desktop, and (like me) you are equally skilled in C# and C++, it's safe to take advantage of the simpler syntax, rich standard libraries, stellar IntelliSense and reduced development effort that C# offers. Those original results showed only a small performance penalty for C# versus C++ with STL. In the second edition this conclusion needs some modifications. First, let's talk C++. How important are the compile switches and special #defines in VC++?
Now what about C#? There aren't any special #defines or switches to make C# code run faster, but of course, the way you write your code can make it run faster or slower.
The most curious new result is the Sudoku test, whose C++ version runs fully twice as fast as C#. Dunno why.
Again, certain "bad" parts of the Microsoft (Dinkumware) STL, like hash_map/unordered_map, are dramatically slower than the equivalent C# and should be avoided. In the C# world, it could be argued that matters are worse, because while you can work around a poor library by writing (or finding) another library, it's harder to work around a compiler that doesn't optimize very well. Now, .NET JITs are not bad, but they can't quite catch up to C++, and certain JITs don't handle certain tasks well (e.g. the x64 JIT was much slower on some tests, but faster than x86 at handling 2D arrays of double). You can sometimes get better performance by fiddling around with pointers, but not always, and who wants to do that anyway?
Meanwhile, the Compact Framework is always slow, with no recourse other than native code. Why so slow? This article by Ryan Chapman sheds some light on the subject. Particularly noteworthy is that the .NET Compact Framework apparently inserts three instructions that are executed on every loop iteration. I'm just speculating, but manual loop unrolling might therefore improve performance significantly. It's not that the CF isn't optimized at all, but you can see that it misses some important optimizations like keeping the loop constant in a register, or combining "add" and "shift" into a single instruction.
Of course, C# coders tend to program in different ways than C++ coders: they use LINQ-to-objects (which can be very slow if used carelessly), they may not tune their algorithms, they may use high-overhead libraries like WPF, prefer XML files to plain text files, use reflection heavily, and so on. These differences can lead to slower programs, but I believe a performance-conscious C# programmer can write programs whose performance is comparable to similarly well-written C++ code. .NET is clearly not as fast as C++ yet, but in principle I see no reason why it couldn't be, given NGen and a lot of TLC from Microsoft.
If you use Mono there will be an extra speed penalty, but depending on what you're doing, it's not too bad. A lot of these tests were hard on Mono, because they tested things it does poorly, such as structure handling and generic Math. Possibly the most realistic tests here are the Square root method, the Sudoku solver and the matrix multiplier. In these tests, Mono was roughly half as fast as C++, and maybe 50% slower than MS .NET, except for Sudoku where Mono was about 27% as fast as C++. On the other hand, it did pretty well in the Dictionary<int,int> test (almost as well as MS .NET).
If you happen to be developing for Windows CE, you'll generally suffer a big performance penalty by using .NET. The Compact Framework can do some tasks well enough (such as reading from a file), but string processing, ordinary loops and arithmetic, structure manipulation and other basic tasks seem to be quite unoptimized. C# would still be acceptable if you won't be doing any complex algorithms or heavy string manipulation. Probably a hybrid solution, where Compact Framework code calls performance-critical C++ over P/Invoke, should be used to overcome its abysmal performance. Mono built for ARM might also offer an improvement, but there is no version currently available for Windows CE.
This article, along with any associated source code and files, is licensed under The GNU Lesser General Public License (LGPLv3)
Quote:My main goal is to measure the performance difference in the compiler/JIT and parts of the standard library that are used most often.
Quote:It is pretty well known that native code is faster: Oh, of course, it was wrong of me to measure the difference! Well, I'm sorry if my CPU betrayed your trust. But my results showed that C++ was slightly faster in general (if you choose good-quality C++ libraries), and dramatically faster on ARM.
// Allocate double ** pp; pp = new double * [1000]; for (unsigned short r = 0;r < 1000;++r) pp[r] = new double[1000]; // Assign for (unsigned short r = 0;r < 1000;++r) for (unsigned short c = 0;c < 1000;++c) pp[r][c] = ...; // De-allocate for (unsigned short r = 0;r < 1000;++r) delete [] pp[r]; delete [] pp;
double a[16][27]; double[,] a = new double[16,27];
for (int i = 0; i < aCols; ++i) // transpose (large-matrix optimization) for (int j = 0; j < bCols; ++j) c[j*bRows + i] = b[i*bCols + j];
General News Suggestion Question Bug Answer Joke Praise Rant Admin
Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.


text:
Samurai Gattai Series 04- Ika Origami
Review by EVA_Unit_4A
"Returning after what seemed to be a false detection of an Ayakashi attack on the Gap Sensor, the Shinkenger find an arrow with a note on it that says "Coming Soon" with Takeru sensing something from before within the house as it starts to haunt him. Deciding to investigate the Gap Sensor, the vassals encounter a sushi-selling man whose hand writing matches the note. After the seller gives them the slip with spicy sushi, Ryunosuke and Mako go to Shojo Valley to find Takeru while Chiaki and Kotoha track down the sushi seller. By the time they find him, ShinkenBlue and ShinkenPink find Shinken Red confronting the Ayakashi Isagitsune who was spying on Takeru to find out the Shiba sealing character. With his mirror medium destroyed, Isagitsune overwhelms the 3 with his magic as Chiaki and Kotoha coming with the sushi seller following. But even all 5 Shinkenger are no match for Isagitsune as they revert to normal as the seller arrives to their aid, transforming into Shinken Gold. After taking out the Nanashi in blinding speed, Shinken Gold battles Isagitsune and destroys him. When Isagitsune revives, he overpowers Tenku-Shinken-Oh until Shinken Gold enters the fight in the Ika Origami to weaken the Ayakashi so Tenku-Shinken-Oh can land the deathblow. After the fight, Takeru reveals to his vassals that he already knows the sushi seller, Genta Umemori."
The Ika Origami is a squid. When not in combat, it hangs out in the glass miniature fish stock tank on Genta's sushi cart, appearing when Shinken Gold attaches the folded Ika Disc onto his Sushi Changer. Though a water-based creature, it can fly through the air, using its five tentacles to 'scoot' and hover. Like a real squid, it can grab onto and pummel Ayakashi monsters with its tentacles, or squirt a cloud of black gas (Squid Ink Cannon) into the air as a distraction or to uncover invisible forces.
To control the Ika Origami, Shinken Gold boards it, and places the Ika Disc onto his Sakanamaru, which he then placed into the command console.
Ika Origami (squid)
The Ika Disc is stored on the 'back' of the head just like in the show, and the two smaller sections can fold out the same way.
Each tentacle has one axis of motion and they all ratchet a limited number of positions. The two larger arms, however, are restricted in their downward motion by the base of the three regular arms.
The two larger arms can be raised, and then the three smaller ones can spin around on their combined base!
Due to the transformation process, the little ink jet on the 'top' of the head can flip up and down a bit, though it does not shoot anything.
The Ika Disc can be placed onto the Hiden Saiseitou ShinkenMaru. When it is spun, you see the black silhouette of the Ika spinning around in place! (Chh, barely- two large separation lines seriously interrupt the animation!)
I opened the box, put the toy together, and my first reaction was, "Whoa- big!" It is definitely bigger than the previous three Samurai Gattai Series sets. It also has more poseability- way more- even if it is just one joint per arm. The spinning lower arms was vaguely reminiscent of a drill without being obviously so. And, oh look at this- no Hiden Disc-powered gimmick! (WTF-!?) I am bummed out a little that the larger arms can't get past the base of the three smaller ones, but I guess having them move at all should be sufficient to quench my thirst for poseable sub-mecha… And even though they didn't have to, I appreciate the extra suckers detail they put under each tentacle.
Compared to the Kabuto, Kajiki, and Tora Origami, the Ika Origami just feels unrestricted, allowing transformation joints to bend in animal-like ways that the others' couldn't. It also, oddly, doesn't have a Hiden Disc gimmick. (Is that good or bad? It's hard to say, in my opinion…)
Sets required for this combination:
- DX Samurai Gattai Shinken-Oh
- Samurai Gattai Series 04 - Ika Origami
Samurai Busou
Ika Shinken-Oh
[Wikipedia's entry on Act 18- "Samurai Promotion"…]
"After the appearance of Shinken Gold, the vassals learn from Jii that Genta was a childhood friend of Takeru whom he obtained Ika Origami from. Before Takeru could explain why, Genta arrives late to declare himself a samurai under Takeru. As Takeru takes a step out, Genta reveals that he has been training himself for this moment before Jii takes the Sushi Changer from him. As the Shinkenger take their leave upon the Gedoushu making their move, Takeru breaks his friend's heart by refusing to accept him as an ally. After nearly losing to the vengeful Ayakashi Hyakuyappa before he falls back into the Sanzu River, Takeru is confronted by the Vassals and Genta confront Takeru on his reasons for turning Genta before Hyakuyappa resumes his attack. Remembering the promise he made with Genta years ago, Takeru acknowledges his friend as a Shinkenger. While the vassals deal with the Nanashi, Shinken Red and Shinken Gold combine their signature moves to destroy Hyakuyappa. After Hyakuyappa revives, Shinkenoh has a hard time until Ika Origami arrived and combines onto Shinken-Oh to form Ika Shinken-Oh who freezes the Ayakashi before destroying him. Soon after the fight, the gang celebrates their newest ally by eating out at the Gold Sushi cart."
The Ika Shinken-Oh is armed with a bladed shield on the right forearm that can use the Squid Spear Line attack. The left hand holds another shield-like weapon that can project a blast of ice (Squid Freezing) to freeze Ayakashi in their tracks. The finishing attack draws lightning to the arms on its back, which channel into the shield on the left forearm for a series of rapid physical strikes, called Squid Flash.
The left weapon does nothing but hang on the left hand, while the Ika Origami's head fins can spring forward a little as part of the Squid Spear Line attack. Additionally, because of its size, the left arm cannot be lowered straight down when holding the weapon.
Oh, come on--! Another trend change in the toy line!? First, the Hiden Disc doesn't activate anything like it did in the last three samurai busou combos, and now we don't get a new headdress. You're telling me those larger tentacle arms couldn't have formed some epic antlers or something for another helmet? And also, what the hell is that thing in the left hand? A shield? A bladed weapon? I honestly don't know; all it does in the series is shoot frozen air, and that's it. On top of which, it's so big and inflexible that the arm can't drop down.
Okay, it's about time a samurai busou got a shield, but, this one really doesn't do it for me. AND, the Hiden Disc doesn't turn to activate the attack gimmick. I like the spear-thingie, but why wasn't it disc-activated like the previous three were (Kabuto Shinken-Oh, Kajiki Shinken-Oh, Tora Shinken-Oh)?
Y- no, not a good upgrade. It's not a giant headdress, but the Ika Shinken-Oh is actually worse because it doesn't know what the hell it is! It's just there, and that is NEVER good enough.
[REVIEWER'S NOTE: since I will not be covering the DX Samurai Kyojin Daikai-Oh for CollectionDX, I also cannot review the Samurai Busou Ika Daikai-Oh combination. I apologize for the inconvenience!]
Sets required for this combination:
- Samurai Gattai Series 01 - Kabuto Origami
- Samurai Gattai Series 02 - Kajiki Origami
- Samurai Gattai Series 03 - Tora Origami
- Samurai Gattai Series 04 - Ika Origami
Shin Samurai Busou
Ika-Tenkuu Buster
The Ika-Tenkuu Buster makes its debut alongside the Shin Samurai Gattai Daikai-Shinken-Oh super combo in Act 24- "The True Samurai Combination". While seen mostly with the Daikai-Shinken-Oh in the series for the finishing attack Origami Grand Release, the Ika-Tenkuu Buster is not restricted in such a way in its toy form. It is a giant energy/spirit-projection cannon mounted atop a tripod, but can only be used once in battle due to the overwhelming drain of mojikara on the six Shinkenger required to fire it.
The only feature of the Ika-Tenkuu Buster is the Origami Grand Release finisher. This is achieved more-or-less the same way as the DaiTenkuu Daigekitotsu from the three-component Samurai Gattai DaiTenkuu- simply release the catch levers on the Kabuto's horn and Kajiki's nose, and then spin the dial on top. Because the Ika Origami component does not connect to the internal gearing of the Tora Origami like the others do, it does not do anything new.
Yeah- this is why you get the Ika Origami, so that you can finish off this ugly monstrosity… The few tabs on the Tora that went unused on the DaiTenkuu were bound to be used for a later super combo, but for an expanded DaiTenkuu??? Didn't see that one coming. I will say, though, that the Ika's parts latch together rather nicely to the rest of the DaiTenkuu.
It's interesting that 1- this isn't an independently-operating mecha like the DaiTenkuu, which is composed of independently-operated mecha; and 2- there is nothing for the Daikai-Shinken-Oh (or any other samurai kyojin robo) to hang on to, so you aren't limited to one combination of ten mecha. (It would have been nice, though, if there had been some generic handles-or-something for them to hang on to…)
What isn't interesting, though, is that PLEX and Bandai worked so hard (err… not really) to get the Kabuto, Kajiki, and Tora to link up for that combined spinning-Hiden Disc-gimmick that they then turned around and completely neglected to work the Ika into the equation! (Know what they coulda done, in my opinion? Leave a hole in the top of the Tora so that a rubber cog under the Ika could link up with it. That way when the Discs spun, the spear head could bounce back-and-fourth just like it does in the series. SEE HOW EASY THAT WAS, PLEX-!?)
So, the Ika Origami becomes part of combinations that should never have been in the first place because they don't know what they are, why they exist, or what to do with themselves. If you don't like the DaiTenkuu, then you may not have a reason to get the Ika Origami.
Posted 17 March, 2011 - 18:37 by EVA_Unit_4A |
4 comments postedSee, this is the reason why I never bothered to buy an add-on Origami from Shinkenger. This toy and the other so-called Origamis definitely kills the "Origami" concept of the toy line. It's unfortunate that only Shinken-Oh was the only one to adopt such a gimmick.
Yes, quite a shame. As I said in my video, if they had been consistent with the whole line, and also kept them all "origami" just like the mecha in the Shinken-Oh, this could have been a really exciting toy line. It's a shame they'll never be able to do that again, and folding paper is now unique to just the Shinkenger world.
i have the shinkenger mecha complete, except for daigoyou and i'm quite happy with Ika. while the combinations are a bit wacky, i do like him as a separate display piece, which all the accessory origami will be on my shelves.
he looks good as a squid just by himself, and displaying the busou-origami separately keeps them from disturbing the looks of the robots themselves.
on a side note, if you want to see shinkenger, i suggest downloading tv-nihon's subbed versions. they're quite high-quality and they have the whole series on megaupload. it'll take you at max a week to download all the episodes
There's an Octo Disk in the "Gold Ranger Training Gear" set that has the praxinoscope images from the Ika Disk... in sticker form on a regular disk. Meaning it actually works with the Spin Sword's praxinoscope. The "Coral Disk" (Sushi Disk) available in the same set or with just the Barracuda Blade is similarly unimpaired by hinges when it comes to the praxinoscope effect.

subset: commoncrawl


text:
Chak Wardak-Syahgerd TOPO Map
Created By: Indrid Cold
Last Updated: December 6th, 2009 3:12pm
Map Coverage:
North: 35°
West: 68°
East: 69°
South: 34°
Country: Afghanistan
Price: Free!
Most Popular Maps
- My Trails-High Quality Trail and POI Maps
- Arizona Topo
- World Topo - Eastern
- Florida Topo
- World shaded relief kmz
Other Maps By Indrid Cold (See All)
This map superseded by http://www.gpsfiledepot.com/maps/view/182/
The purpose of this map is to provide map coverage of West of Kabul and the surrounding area.
For a detailed metro map of Kabul, use the Kabul City Map.
- Roads, settlements and water data including irrigated areas.
- Points of Interest, such as Med centers...
- 20 foot topographic contours
- English Transliteration, not: کابل
Coverage & Detail
The following MapSource screenshot shows the detail:
GPS screen shots:
Screen shot from RoadTrip:
Two options exist;
for Windows, download and run setup. The map will then appear in Garmin MapSource and can be added to your GPS by selecting it in MapSource and sending it to the GPSr.
For OS X, download the Mac .dmg version, double click it to mount the file. Instructions are in the Read First file.
Download Windows Version [142B] (1297 Downloads)
Download Mac Version [142B] (880 Downloads)
Need MapSource (Windows)? Click Here
Need RoadTrip/MapInstall/MapManager (Macintosh)? Click Here
GPS Usage
This map can be installed with any other Garmin Maps via Garmin MapSource or MapInstall (MapSource How-To Tutorial).
Version 1.01 (17 Dec 08)
- Set levels to match new mapsets.
- Removed diacritics that didn't display properly on some Garmin units.
- General cleanup of NGA set.
- New Macintosh installer.
Version 1.00 (30 Nov 08)
- Initial release


text:
With the recent discovery of the Mebromi BIOS firmware virus/MBR rootkit in the wild are we now actually in the age of Advanced Persistent Threats (APT) for personal computers and does that imply the malware solutions of the last two decades are obsolete?
The APT term has been thrown around for some time in reference to state-level attacks like Stuxnet or cooperate-foundation-shaking events such RSA SecureID, Sony PS Network, and the recent PKI CA compromises. This discovery appears to differ from those events.
Those high value target events all either needed an APT attack to penetrate the layers of defense or the story of same to protect the reputation of the victim. Unlike those high value targets, the Mebromi virus is designed to work against mundane PCs with the Award BIOS running the previous generation of the Windows OS. The technology employed has been seen separately and discussed in theoretical papers. This forum has cogitated over the theory vs. reality nature of firmware flashed attacks in the last few months relative to video card firmware persistent attacks. Is it time to consider that debate over and declare viable, zero day, common user system APTs are here? If so, is it not also time to reevaluate the find, patch, rinse, and repeat method of malware protection?


text:
Gallup: More Americans Were Uninsured in 2011
Texas continues to be the state with the highest percentage of residents without health insurance, according to the latest Gallup health survey on insurance coverage in the United States.
The report released Friday found for the fourth year Texas had the most uninsured citizens, with the gap between other states widening. At 27.6 percent, its rate is more than four percentage points higher than the next highest state, Mississippi.
Massachusetts remains the state with the lowest percentage of uninsured, at 4.9 percent. Vermont, Hawaii, Connecticut, Minnesota, and Wisconsin also have uninsured rates below 10 percent.
No state showed a consistent decline in uninsured since 2008, when Gallup began tracking this information. Nationally, Gallup found year-to-year increases in the percentage of uninsured at the national level, with an increase from 14.8 percent to 17.1 percent over the last four years.
Adults aged 18 to 25 were less likely to be uninsured than in past years, due to a new provision of the 2010 health care law that allows young adults to be on their parents health insurance until age 26. Hispanics were most likely to be uninsured, with more than 40 percent not having health coverage in 2011. In addition, more than 30 percent of low-income Americans were uninsured in 2011, which has been on the incline since 2008.
Poll results are based on telephone interviews between Jan. 1 to Dec. 31, 2011, with 353,492 participants over the age of 18 living in all 50 states and the District of Columbia.


text:
Darrell Sinclair had been searching for his biological father for 22 years.
Last week, he got to meet him for the first time after an Ancestry DNA test and hard digging by his wife Melanie, who made it her mission to make it happen.
All Darrell knew was that his mother became pregnant with him at 15 after a summer fling in Port Moody with a construction worker from Ontario.
His mother would eventually marry another man and had two girls.
Darrell met Melanie in 1997. Together they decided they were going to look for his father.
He told Melanie that he had previously found a baby book with the name Doug Sherk handwritten beside the title father, then crossed out. That is how the couple's search began.
Melanie knew Darrell's biological father was from Ontario, but ended up talking to men with the same name in Pennsylvania and Ohio, as well, but to no avail.
In December 2018, Melanie and their two children – Noah, 9 and Abigail, 4 – bought Darrell an AncestryDNA kit for Christmas. They were going to give it to him for his birthday in March, but were too excited.
Still, the kit sat on a shelf until March 8, when Darrell decided he was ready to take the DNA test. He spat into a tube and sent the sample to Australia.
When the results came back, Darrell found a match to a familiar name: Sherk.
Darrell's DNA matched a man named Brian Sherk, whose DNA results were already in the company's database.
Melanie looked up Brian Sherk on Facebook and he told her he was not the right man because he had never taken the DNA test, but that he was friends on Facebook with a man with the same name and who he is related to.
Melanie wrote to the other Brian Sherk. He was pretty sure his great uncle and aunt were Darrell's biological grandparents. Sherk sent her an obituary.
Melanie saw that a man named Doug Sherk was listed as one of the children in the obit. She had messaged another man on Facebook by the same name two years earlier, but received no reply. This time, she was going to look for his wife, Sheryl, whose name appeared in parentheses.
When she found Sheryl on the social media site, she also saw a picture of Doug and realized that the couple had two daughters.
She messaged the daughters and received a reply from one of them, Rachel.
Melanie asked her questions about her father, then told her that she might want to sit down before telling her that she thought her husband was Rachel's brother.
Rachel gave Melanie Doug's number and asked him directly if it was possible that he had a child in B.C. and he said that it was.
Doug met Darrell and his family for the first time on April 4. He had surprised them when he let them know he'd be flying in from Medicine Hat, Alta., where he now lives with his wife.
The Sinclair family met Doug at Vancouver International Airport, all holding signs.
Darrell's sign read: "The search is over! 40 years later … Nice to meet you dad".
Noah's read: " We made a wish and it came true. We are so happy we found you."
Abigail: "Welcome Papa Doug."
They brought Doug to Ridge Meadows Hospital to meet Darrell's grandmother, Beatrice Laurene Meger, who at 78, was suffering from leukemia and dementia. It was her dying wish to see father and son reunited.
"She said, 'I held on for this moment,'" Melanie said.
Meger passed away on Wednesday morning, her wish fulfilled.
The Sinclair family plans to visit Doug and Sheryl in May and meet the rest of the family and also plans to attend a family reunion in Ontario next year.
Like us on Facebook and follow us on Twitter


text:
Create a Website Account - Manage notification subscriptions, save form progress and more.
Accepted Scrap Metal: Metal items that are at least 80% metal; some acceptable items include bicycles, water heaters, tools, washers, dryers, dishwashers, file cabinets, metal chairs, and gas grills (without propane tanks). Unacceptable items: Propane tanks, any item containing freon such as air conditioners, refrigerators, or dehumidifiers.
Show All Answers
Automotive-related items: DPW Yard accepts: oil filters, motor oil, tires and car batteries are accepted. The oil is used to heat the DPW building so it must be as clean as possible. Tires are also accepted (with the exception of commercial tires which are not accepted). Please limit your tire disposal to 2 per month. Items not accepted: gasoline, anti-freeze, contaminated motor oil. These items, however, can be brought to the DPW during the Hazardous Waste Collection Day (typically the last Saturday in September).
Batteries are a unique product comprised of heavy metals and other elements. Some of these toxic heavy metals include nickel cadmium, alkaline, mercury, nickel metal hydride and lead acid. It is these elements that threaten our environment if not properly discarded.
Not all batteries are the same, and there are different ways to ensure each type is properly discarded or recycled. The batteries that consumers use most include household alkaline batteries, nickel-cadmium (NiCd) batteries, nickel metal hydride (NiMH), rechargeable batteries, button cell, automotive and non-automotive lead based batteries.
That's a lot of batteries – how do you know what type you are using? The following information might help:
Household/Alkaline batteries are common, single-use batteries – AA, AAA, C and D. These batteries have little to no mercury in them and recycling programs generally no longer accept them. In Gloucester, we do not. It is perfectly safe to dispose of them in the trash.
Nickel-Cadmium (NiCd) are rechargeable batteries- considered to be hazardous waste, and MUST be recycled.
Nickel Metal Hydride (NiMH) or Lithium-Ion are commonly used in laptops. They are considered non-hazardous waste but contain elements that can be recycled.
Button cell batteries are commonly used in hearing aids, calculators, and watches. These batteries contain silver, mercury, and other elements that are hazardous to the environment and should be recycled.
Automotive & sealed lead-based batteries contain hazardous materials and elements that can be reused and should be recycled as well.
Clothing & Shoes: The Salvation Army and Goodwill both collect and resell clothing at low prices and use the proceeds to fund their own charitable activities, so donations help make a positive difference on multiple levels. Put clothes in a drop box run by a charity. Donation drop boxes are usually located in the parking lots near stores or shopping centers. You should check beforehand that the charity name on the box is a legitimate one--there are many organizations that use items donated in drop boxes for their own profit, rather than for helping others. Contact local homeless shelters and ask if clothing donations are needed. See if there are any specific clothing items that they need most. Action, Inc., Second Glance, Planet Aid boxes, Winter clothing is always in demand during the winter for warmth drives commonly held at schools, banks, community centers, and places of worship. Special items: such as prom dresses for teens who may not be able to afford to purchase one. Business/professional attire is often collected to help people in interviewing for jobs; Wellspring in Gloucester or other organizations (Rosie's Place in Boston, MA). Organizations for Clothing/Shoes "Beyond the Bin", Big Brother Big Sister Foundation, Salvation Army, Second Glance. Current Drop Box Locations: Hiltz Disposal, 24 Kondelin Road, Gloucester, MA (accessible M-F 7:00 am - 4:00 pm), JD Myers Pub, 24 Lexington Avenue, Gloucester, MA, Holy Family Parish, 74 Pleasant Street, Gloucester, MA, Red Barrel Restaurant, 171 Eastern Ave, Essex, MA, Tony Tally Motor Sales, 209 Essex Avenue, Gloucester, MA, Dawn's Studio of Dance, 42 Eastern Avenue, Gloucester, MA.
Electronics/E-Waste Staple's Office Store locations generally accept electronics and e-waste to no cost to you —regardless of brand, condition, where it was purchased. For more information of Staple's Recycling Program, visit Staples.com.
The DPW Yard accepts fluorescent light bulbs.
Furniture: Second Glance on Pond Road, Gloucester has a furniture annex. Second Glance is part of the Open Door Food Pantry's fundraising activities; both are non-profits and all monies raised through the sale of their furniture and other goods go directly to feeding hundreds of families on Cape Ann. For hours of operation, to schedule a pickup, or make an appointment, call (978) 283-4298 or visit their website Open Door Food Pantry. Beyond The Bin also has information on where to recycle furniture.
Glass: Glass is an integral part of any recycling program. Recycling diverts this valuable resource from land-filling and incineration. Consumers expect glass to be included in recycling programs. Although not as prevalent on grocery shelves as they used to be, glass bottles and jars still have a presence and need to be recycled when empty. Whether they once held beer, wine, spaghetti sauce, baby food, or salsa, glass containers are easy to recycle because they can easily be recycled back to new glass. Inexplicably, only about 22 percent of glass bottles and jars are recycled nationally. Massachusetts recycles 66 percent due in part to our deposit laws on beverage containers. But aside from getting your nickel back for your bottles, why should you recycle glass bottles and containers? Glass is forever. Glass can be recycled an infinite number of times; it really does get recycled! The same glass bottle or jar can be recycled over and over again into the same high quality glass every time. Glass bottles and jars go from recycling bin to store shelf in as few as 30 days. An estimated 80 percent of recovered glass containers are made into new glass bottles. Glass saves energy. By using recycled glass cullet, the glass container industry reduces the amount of energy it needs for its furnaces. Using recycled glass minimizes consumption of raw materials and lessens the industry's overall demand for energy. Plus it's cost efficient. The glass recycling process is a closed-loop system, creating no additional waste or by-products. Glass recycling lessens greenhouse gas emissions. For container glass, a 10 percent increase in cullet reduces particulates by 8 percent, reduces nitrogen oxide by 4 percent, and reduces sulfur oxides by 10 percent. And, for every six ton of recycled container glass used, one ton of carbon dioxide, a greenhouse gas, is reduced. Glass saves raw materials. For every ton of glass recycled, more than a ton of raw materials are saved, including 1,300 pounds of sand, 410 pounds of soda ash, 380 pounds of limestone, and 160 pounds of feldspar. Save the landfill; Save the World. Recycling glass helps to preserve natural resources while lessening the load on landfills—and helping communities avoid expensive disposal costs. While the majority of recycled glass is made into new glass bottles and jars, glass can also be remade into other products. The second largest market for recycled glass is fiberglass. Other markets include abrasives, glass asphalt glass beads for reflective paint and filler in storm drains.
To find out where to recycle, reuse, or re-purpose items n Massachusetts, use the searchable database, Beyond The Bin which is administered by Massachusetts Department of Environmental Protection.
In the recycling world, the term is "single stream"; the sorting technology and workers in the sorting plants do the separation, with conveyor belts carrying each type of recyclable to a different place, so now, you can put most everything in together. No more putting recyclable paper and cardboard in a separate bin or putting recyclable cans, bottles, and plastics in a separate bin! Recycling your trash is an important way you can help preserve our environment, reduce our consumption of precious natural resources, save yourself and our City money. The more you put out for recycling, the less you have to spend on bags. Only with your help can we reach our recycling goals. Each item that is removed from the waste stream reduces our trash disposal costs, enabling us to use that money for other important city services - all while helping to preserve our environment! The main reason heard from residents who don't recycle is that it is too much trouble for them to sort their recyclables and that the bins take up too much room with paper and junk mail in one bin and everything else in another. You can use an old trash barrel with a "Recycle" bumper sticker on it (stickers are available at the DPW at no cost). Now there is absolutely no excuse not to take part. And recycling is mandatory! Mandatory recycling ensures that we get recyclables out of the trash and therefore out of the incinerator in Saugus where Gloucester pays an additional fee for every ton of trash taken there. NOT RECYCLABLE/CONSIDERED REGULAR TRASH: Plastic bags of any kind including: pellet bags, styrofoam, bubble wrap, spray bottle pumps, deli & salad plastic containers, plastic disposable plates & cups, disposable silverware, napkins, styrofoam coffee cups, 3 ring binders, CDs and video tapes, greasy/food stained pizza boxes and paper with food stains.
This Beyond the Bin Directory is meant to help you recycle unique and hard-to-handle items that don't go in your recycling bin or recycling cart. While some of the outlets listed in this directory may accept material that have traditionally been handled by municipal recycling programs (such as paper, cardboard, bottles, cans, etc.), many of the outlets listed here do not accept these materials.
MassDEP provides an alphabetical listing of municipal recycling programs.
Wheels For Wishes is a charity vehicle donation program that turns cars, trucks, motorcycles, SUVs, RVs, and even boats into wishes for children in Massachusetts and Rhode Island. They are a tax-exempt charity under section 501(c)(3) of the IRS Code, benefiting the Make-A-Wish Foundation® of Massachusetts and Rhode Island. Contact the organization at (855) 641-9474 for more information or to arrange a donation. Visit their website at www.wheelsforwishes.org.
Sharps needles may NOT be disposed of in the trash. Addison Gilbert Hospital on Washington Street has a Sharps Disposal Kiosk in their main lobby; the needles must be in a puncture-resistant plastic container. For more information, call the Gloucester Health Department at (978) 281-9771.
The three recycling arrows is the universal symbol of recycling and printed on millions of products that can be recycled or have been made from recycled content. Each arrow in the recycling logo represents one step in the three-step process that completes the recycling loop. Step #1 is collection. This is when you put your recyclable materials into your curbside recycling bin. The collected materials are then processed and sold to manufacturing facilities such as steel, paper, and glass mills. Step #2 is the manufacturing process; the recyclable materials are converted into new products and shipped to stores across the country to be placed on shelves as new consumer goods, for example: Paper and cardboard are turned into cereal and cracker boxes, book covers, and game boards at a recycling paper mill in Fitchburg, MA. Glass bottles and jars are melted and used to make new containers in facilities such as St. Gobain Containers in Milford, MA. Milk jugs, detergent bottles, and other #2 plastics become landscaping timbers and whiskey barrel planters made by Smartware Products in Leominster, MA. Be careful! The 3-arrow recycle symbol can be misleading. It's not a recycling stamp, even though the graphic is clearly slated towards recycling. It's a "resin recycling code", which tells you what kind of plastic you've got. The recycling symbol does not necessarily mean that a product is made with recycled content or that it can be recycled in the City's curbside collection program. Many plastic products are coded with a recycling symbol, indicating that somewhere they may be recyclable, but not necessarily accepted in Gloucester's curbside program, for example: Codes 1 and 2 (milk bottles and soda bottles) are easily recycled. The other codes usually aren't. Styrofoam (technically, "expanded polystyrene foam"); is code 6. You can't recycle it in the sense of reducing it to constituent parts and making something new out of it (the way you can with codes 1 and 2) therefore even though it is stamped #6 it is not accepted in Gloucester's curbside program . Step #3 of the Recycling Process is where you, the consumer, purchase products made with recycled content. "Buy Recycled" Myths: Here are four common myths and misconceptions about recycled products: Myth #1: "Recycled products are hard to find" This used to be true, but no longer. From the neighborhood grocery store to national retailers, stores sell thousands of products made from or packaged in recycled content material. Myth #2: "Recycled paper isn't as good as non-recycled paper" Recycled content papers now share the same printing and performance characteristics and looks and acts the same as new paper. Recycled content paper has the same whiteness and brightness attributes as well. Recycled papers offers the same level of performance on copiers, and laser and ink jet printers. Myth #3: "Recycled products cost more". This used to be the case for some materials, but no longer. Many recycled products are priced competitively with their non-recycled counterparts and in fact, may cost less. Myth #4: "Recycled products are inferior in quality" This is simply not true. Recycled products have the same quality, reliability, and dependability. Surveys by the 'Buy Recycled Business Alliance' asked hundreds of corporate purchasing agents about their satisfaction with recycled content products; 97% of respondents were pleased with the performance of recycled content products. When you "Buy Recycled" you complete the recycling loop!
The DPW/Recycling Department holds two Residential Hazardous Waste Days, typically one in the spring and one in the fall. Gloucester residents are allowed to bring up to 25 pounds or gallons of material at no cost. For over 25 pounds/gallons, an additional fee will be assessed. For up to 10 gallons or pounds over it is $30.00, 11-25 gallons or pounds over the charge is $50.00. Acceptable Household Materials Include: Rubber Cement, Airplane Glue, Fiberglass Resins, Photo Chemicals, Chemistry Sets, Furniture Polish, Floor & Metal Polish, Oven Cleaner, Fluorescent Bulbs, Mercury-Bearing wastes, Drain & Toilet Cleaner, Spot Remover Rug & Upholstery Cleaner, Hobby/Artist Supplies. Acceptable Yard-type Waste: Poisons, Insecticides, Fungicides, Chemical Fertilizers, Weed Killers, Moth Balls, Flea Control Products. Acceptable Workbench Waste: Oil Based Paints only, Stains & Varnishes, Wood Preservatives (except Penta), Paint Strippers and Thinners, Solvent Adhesives, Lighter Fluid. Acceptable Garage Waste: Fuels/Gasoline/Kerosene, Motor oil, Car batteries, Antifreeze, Engine Degreaser, Brake Fluid/Carburetor Cleaner, Transmission Fluid, Car Waxes and Polishes, Driveway Sealer, Roofing Tar, Swimming Pool Chemicals. Unacceptable Materials - Do NOT Bring any of the following: Latex Paint (to dispose of latex paint, pop lid, let dry, throw in trash...acceptable), Empty Containers, Trash, Commercial or Industrial Waste, Radioactive Waste, Smoke Detectors, Infectious & Biological Wastes, Compressed Gas Cylinders (other than propane), Ammunition, Fireworks, Explosives, Flares, Fire Extinguishers, Prescription Medicines/Syringes, Asbestos. How Can I Safely Transport These Hazardous Materials? (Important: Never Ever Mix Chemicals!) Leave materials in original containers, tighten caps and lids. Sort and pack separately: oil paint, pesticides, and household cleaners. Pack containers in sturdy upright boxes and pad with newspaper. Pack your car and drive directly to the site. NEVER SMOKE while handling hazardous material. During the residential hazardous waste day collections, residents are asked to schedule an appointment to bring their materials to the DPW yard. The Recycling Department can be reached at (978) 325-5600. Check the City's website in the spring and fall to find exact dates; typically April and September.
The DPW has a special collection on a specific schedule where Christmas trees and wreaths are picked up on residents' regular trash days. Check the website, Gloucester Daily Times, or call the DPW to find out the schedule. According to the National Christmas Tree Association, 25-30 million real Christmas trees are disposed of in the U.S. per year.


text:
The 3GPP has approved technical specifications for 40 MHz of AWS-4 spectrum controlled by Dish Network. The 3GPP's approval will allow Dish the necessary technical blueprints needed to design and build everything from cell phone chipsets to broadband networks.
Dish is now urging the FCC to follow suit and approve a new set of rules that would give it the final go-ahead to deploy an LTE Advanced network on the spectrum.
Over the past several months, Sprint Nextel has petitioned the FCC to reduce the power levels of Dish's spectrum so that it won't interfere with H-block spectrum, which Sprint is waiting to acquire.
If granted, Sprint's request would reopen Dish's 3GPP specifications, causing further delay to a process that Dish started more than 20 months ago.
In an ex parte filing with the FCC on Thursday, Sprint reiterated its call to shift Dish Network's AWS-4 band up 5 MHz from 2000-2020 MHz to 2005-2025 MHz so that adjacent H-block PCS spectrum can be used for LTE.
Sprint claims that if the FCC were to limit the H-block to only small cell use or air-to-ground communication, it likely would not bid on that spectrum. Dish has argued that a "full-power" H-block would cause at least 25 percent of its uplink to become unusable, a claim Sprint has said is erroneous.
Jeff Blum, senior vice president and deputy general counsel for Dish, called Sprint's proposal a "zero-sum approach" that "does not result in net spectrum gain for the American consumer and creates no new jobs."
"Worse yet, it takes 5 MHz of spectrum out of the hands of a new market entrant and puts it in the hands of an incumbent that already has more than 200 MHz of wireless spectrum," Blum said. "This makes no sense at a time when the nation is enduring a spectrum crunch and would benefit from more wireless competition."
Dish Network Chairman Charlie Ergen has been vocal about how any further delays in the FCC's approval process will affect his company's plans to put the spectrum to use.
At the PCIA conference in October, Ergen said he was disappointed at how long it has taken the FCC to act on the matter. Ergen argued that further delays caused by acceptance of Sprint's proposals would hurt Dish's ability to compete with operators like AT&T and Verizon Wireless and said the company may be forced to sell the spectrum if it takes any longer.
Along with Sprint, MetroPCS has commented on Dish's entry to the broadband space. MetroPCS has asked that Dish be required to relinquish 30 MHz of its allocated spectrum in the top major metropolitan areas in the U.S., while retaining 40 MHz in all other markets, in exchange for increased flexibility on all of the AWS-4 licensed spectrum that it retains.
MetroPCS went so far as to initiate a study to gauge the technical aspects of its proposal, but on Thursday, the carrier informed the FCC that due to "other priorities," it had ceased work on that study.