Archive

Archive for the ‘technic’ Category

reverse bits in a byte

July 25th, 2013 No comments

Working on a code for an arduino project I had the problem that the letters i had created for my 8×8 LED matrix were all mirrored. A letter looks like this:

byte letter_A[8] = { 0x0C, 0x1E, 0x33, 0x33, 0x3F, 0x33, 0x33, 0x00};

Now the rows are in the correct order (letter not upside down), but the leds of one row are wrong meaning the LSB should be the MSB. I found 3 solutions on the net which are all 3 cool in their own way:

The first version is a 1 to 1 translation of how i would do it on paper. Take the most left and swap it with the most right. Then take the second and swap it with the second last and so on …

// "00110011" becomes "11001100"
byte byteShift(byte num) {
  byte var = 0;     
  int i, x, y, p;
  int s = 8;    // number of bits in 'num'.
 
  for (i = 0; i < (s / 2); i++) {
    // extract bit on the left, from MSB
    p = s - i - 1;
    x = num & (1 << p);
    x = x >> p;  
    // extract bit on the right, from LSB
    y = num & (1 < < i);
    y = y >> i;
 
    var = var | (x < < i);       // apply x
    var = var | (y << p);       // apply y
  }
  return var;
}

The next version uses bit masks for reversing the order of bits

// Reverse the order of bits in a byte. 
// I.e. MSB is swapped with LSB, etc. 
byte Bit_Reverse( byte x ) 
{ 
    //          01010101  |         10101010
    x = ((x >> 1) & 0x55) | ((x < < 1) & 0xaa);
    //          00110011  |         11001100 
    x = ((x >> 2) & 0x33) | ((x < < 2) & 0xcc);
    //          00001111  |         11110000 
    x = ((x >> 4) & 0x0f) | ((x < < 4) & 0xf0); 
    return x;    
}

The last one is not pretty but pretty fast ;-)

// 36 bytes small, inelegant assembler, but faster 
byte bitswap (byte x)
{
  byte result;
 
    asm("mov __tmp_reg__, %[in] \n\t"
      "lsl __tmp_reg__  \n\t"   /* shift out high bit to carry */
      "ror %[out] \n\t"  /* rotate carry __tmp_reg__to low bit (eventually) */
      "lsl __tmp_reg__  \n\t"   /* 2 */
      "ror %[out] \n\t"
      "lsl __tmp_reg__  \n\t"   /* 3 */
      "ror %[out] \n\t"
      "lsl __tmp_reg__  \n\t"   /* 4 */
      "ror %[out] \n\t"
 
      "lsl __tmp_reg__  \n\t"   /* 5 */
      "ror %[out] \n\t"
      "lsl __tmp_reg__  \n\t"   /* 6 */
      "ror %[out] \n\t"
      "lsl __tmp_reg__  \n\t"   /* 7 */
      "ror %[out] \n\t"
      "lsl __tmp_reg__  \n\t"   /* 8 */
      "ror %[out] \n\t"
      : [out] "=r" (result) : [in] "r" (x));
      return(result);
}

Categories: arduino Tags:

D-Wave Systems und der “Quantencomputer”

May 24th, 2013 No comments

Seit längerem gibt es diese Firma names D-Wave Systems und genau so lange behaupten die schon einen funktionierenden Quantencomputer gebaut zu haben. Einer der lautesten Kritiker war immer Scott Aaronson, ein Dozent am MIT. Scott hat das was D-Wave macht von rund heraus als Unfug bezeichnet. Im Prinzip war auch von vornherein klar das die D-Wave Computer keine QC im klassischen Sinne sein können. Letztes Jahr publizierte D-Wave allerdings einen Artikel in Nature und erklärte das Funktionsprinzip ihrer Maschinen, sie nennen das Quantum Annealing. Die Kritiker verstummten dann für eine Weile, denn das Paper macht Sinn und das Prinzip lässt sich im Grunde auch umsetzen. Neue Schlagzeilen machte D-Wave nun vor Kurzem, als Google und die NASA ankündigten jeweils eine D-Wave Two zu kaufen. Die Kritik wird indes wieder lauter, vor allem von Scott Aaronson: Ein neues Paper von zwei Forschern der USC beweist nämlich das es auf einer D-Wave One keinen Speedup gegenüber klassischem Simulated Annealing gibt. Das sollte nicht so sein. Die Sache bleibt aber dennoch spannend, denn das Paper beweist auch, dass es tatsächlich Verschränkung in dem Rechner gibt. Außerdem wurden die Tests auf einer One gemacht, die hat nur 108 “Qubits”, die Two von Google oder NASA hat dagegen 512 “Qubits”.

Categories: hpc Tags: , ,

Volumenbeschränkung

April 22nd, 2013 2 comments

Das ist der Dammbruch: https://www.telekom.com/medien/produkte-fuer-privatkunden/184370, Volumenbeschränkung im Festnetz. Die Volumen sind zwar nicht so lächerlich wie bei LTE oder UMTS aber immerhin. Ich habe zum Beispiel eine 16MBit/s Leitung, damit könnte ich gerade mal rund 10h bei voller Bandbreite downloaden. Zehn Stunden sind aber nur rund 1,4% der Zeit des Monats. Mit anderen Worten die Telekom verkauft mir ab Mai (Vorsicht Blogeintrag lesen) ein Produkt was ich nur ein hundertstel meiner Zeit nutzen kann. Stellt Euch mal vor, der ÖPNV fährt nur 1,4% der Zeit, oder Kindergärten nehmen nur Zehn Stunden im Monat Kinder auf … Gut die Telekom drosselt dann ja “nur” auf 384kbit/s … also sagen wir jeder Kindergarten nimmt 98,6% der Zeit nur 3 Kinder auf.

So Etwas kann man sich nicht ausdenken. Vor allem stört mich das Argument, die Netze seien überlastet. So wie die Regelung jetzt umgesetzt wird (UMTS LTE), ist die Last auf den Netzen am Anfang des Monats ja noch genau so hoch und flacht dann langsam ab wenn alle in ihr Limit rennen. Oder andersherum argumentiert, wenn die ISP nicht genug Geld für den Ausbau der Netze zur Verfügung haben, dann sollen Sie halt die Preise erhöhen. Ich kaufe einen Service und will mir nicht darüber Gedanken machen, wie, wann und wieviel ich davon nutzen kann. Oder noch anders, der Traffic selber kostet die Telekom ja nichts, wieso soll also dafür Geld verlangt werden?

Fazit: In Zeiten von Full HD Streaming, Cloud und 24/7 Internetradio wächst nun mal das Datenvolumen, kommt damit klar oder macht Euren Laden dicht!

Categories: news, technic, wtf Tags: , , ,

How to drive High Power LEDs

January 7th, 2012 2 comments

Well, I did it wrong last time ;-)

From 28C3 Lightning Talks

Categories: arduino, nerdcore Tags: , , ,

NAT for IPv6

November 25th, 2011 1 comment
Categories: linux, technic Tags: ,

TRIM Speedup on OS X Lion using Full Disk Encryption

November 20th, 2011 No comments

I was quite surprised to see the speed up achieved by enabling TRIM support on Lion using TRIM Enabler. After I enabled it, I created a big file, deleted it (thus freeing/trimming the no longer used blocks) and rewriting another file of the same size:

jupp@x / > dd if=/dev/zero of=zero bs=1m count=$((6*1024))                                                                                                                                                                                                                                                                            
6144+0 records in
6144+0 records out
6442450944 bytes transferred in 71.336086 secs (90311248 bytes/sec)
jupp@x / > rm zero                                                                                                                                                                                                                                                                                                                      jupp@x / > dd if=/dev/zero of=zero bs=1m count=$((6*1024))                                                                                                                                                                                                                                                                              
6144+0 records in
6144+0 records out
6442450944 bytes transferred in 55.568795 secs (120149352 bytes/sec)

That’s a 1.33 speedup for sequential writing. This should not effect reading, of course. As you can imagine, the benefits for random IO on small blocks will be much higher than that.

This shows that the on-chip garbage collector in the SSD drive is (as expected) unable to do anything if full disk encryption is used, requiring the use of TRIM in order to keep write performance high. However, be warned: the use of TRIM could potentially compromise the invisibility of your main partition if using a fake partition for plausible deniability.

I’m using a MacbookPro6,2 and an Intel SSDSA2CW120G3.

Disclaimer: I’m aware that using dd in this fashion in order to achieve quantitive benchmarking results is not recommended. It was just a quick hack to demonstrate that it’s freakin faster with TRIM.

Revolution oder alte Kamellen?

November 2nd, 2011 2 comments

Grad einen Artikel über eine “bahnbrechende” Software gelesen. Sie soll die Fähigkeit besitzen sequenziellen, modularen Code ohne großen Aufwand automatisch zu parallelisieren. Das ist eigentlich der Traum jedes 08/15-Programmierers, aber würde meinen Job obsolet machen.

Im ersten Moment dachte ich: “automatisch” -> Blödsinn -> geht nicht. Im zweiten dann: gabs schon (siehe z.B. HPF oder UPC) -> nix neues -> warum also ein Patent? Und dann ist mir das “modulare” aufgefallen. Es scheint also, dass sie eine Software entwickelt haben, die in der Lage ist sequenziellen Code, der aus unabhängigen Abschnitten besteht, “embarrassingly parallel” auszuführen. Und das wäre nun nicht grad einem Patent der Kategorie “no prior art” würdig.

Momentan hab ich aber nicht grad viel dazu gefunden, außer den Artikel und ein Video auf der Webseite der Software. Die/der Entwickler wollen das ganze auf der SC11 vorstellen. Vielleicht hat ja einer von euch (die zur SC reisen) mal Zeit sich den Spaß anzuschaun. Würde mich echt interessieren, aber ich geh momentan eher von einer Luftnummer aus.

Categories: hpc, nerdcore, software Tags: , ,

nerd-stuff

July 3rd, 2011 1 comment
Categories: fun, hardware Tags: , ,

Interesting Papers on ICCS 2011

June 9th, 2011 No comments

Here is a (surely subjective) list of interesting papers from ICCS11. We saw some of the presentations of the papers (see “*”). The list is not sorted in any way.

Categories: hpc, science Tags: , ,

Intels Tri-Gate Technologie

May 9th, 2011 No comments

Sehr lesenswerter Artikel im insideHPC Blog über die neue FinFET 3-D FET Tri-Gate Wundertechnologie von Intel. Da scheint gerade jemand echt Angst vor ARM zu haben. IMHO ist der Fehler von Intel ja schon früher passiert, und zwar an der Stelle der Geschichte als sie die Chance hatten x86 den Todesstoß zu versetzen, es aber nicht getan haben. Aber lest selbst:

http://insidehpc.com/2011/05/09/intels-tri-gate-gamble-its-now-or-never/

Categories: hardware, technic Tags: , , ,