NerdyRoom™

Well, I did it wrong last time

From 28C3 Lightning Talks

Well, I did it wrong last time ;-) httpv://www.youtube.com/watch?v=kHdAkQFLC3g From 28C3 Lightning Talks

Nur um es mal irgendwo vermerkt zu haben: es scheint NAT für IPv6 zu geben.

http://www.heise.de/newsticker/meldung/Netfilter-Entwickler-arbeiten-an-NAT-fuer-ip6tables-1384952.html

Nur um es mal irgendwo vermerkt zu haben: es scheint NAT für IPv6 zu geben. http://www.heise.de/newsticker/meldung/Netfilter-Entwickler-arbeiten-an-NAT-fuer-ip6tables-1384952.html

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.

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.

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.

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.

I really do like the basic idea behind this “hardware-mashup”, a wristwatch made out of the ipod-nano:

http://vimeo.com/18932376

More info can be found here: http://lunatik.com/

I really do like the basic idea behind this "hardware-mashup", a wristwatch made out of the ipod-nano: http://vimeo.com/18932376 More info can be found here: http://lunatik.com/

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.

• Cellular Microscopic Pattern Recogniser – A Distributed Computational Approach for Macroscopic Event Detection in WSN; Waleed M. Alfehaid and Asad I. Khana
• Parallel application benchmarks and performance evaluation of the Intel Xeon 7500 family processors; Piotr Kopta, Michal Kulczewski, Krzysztof Kurowski, Tomasz Piontek, Pawel Gepner, Mariusz Puchalski and Jacek Komasa
• Early performance evaluation of AVX for HPC; Pawel Gepner, Victor Gamayunov and David L. Fraser *
• Gleipnir: A Memory Analysis Tool; Tomislav Janjusic, Krishna Kavi and Brandon Potter
• User-defined events for hardware performance monitoring; Shirley Moore and James Ralph *
• Massively parallel FPGA-based implementation of BLASTp with the two-hit method; Lars Wienbrandt, Stefan Baumgart, Jost Bissel, Florian Schatz and Manfred Schimmler *
• Coarse Grained Parallelized Scientific Applications on a Cost Efficient Intel Atom Based Cluster; Robin Geyer, Andy Georgi and Wolfgang E. Nagel *
• 10×10: A General-purpose Architectural Approach to Heterogeneity and Energy Efficiency; Andrew A. Chien, Allan Snavely and Mark Gahagan *
• High Performance Stencil Code Algorithms for GPGPUs; Andreas Schäfer and Dietmar Fey *
• Linux Cluster in Theory and Practice: A Novel Approach in Teaching Cluster Computing Based on the Intel Atom Platform; Andy Georgi, Stefan Ḧohlig, Robin Geyer and Wolfgang E. Nagel *
• 145 TFlops Performance on 3990 GPUs of TSUBAME 2.0 Supercomputer for an Operational Weather Prediction; Takashi Shimokawabe, Takayuki Aoki, Junichi Ishida, Kohei Kawano and Chiashi Muroi
• Parallel k-Means Clustering for Quantitative Ecoregion Delineation Using Large Data Sets; Jitendra Kumar, Richard T. Mills, Forrest M. Hoffman, and William W. Hargrove
• Lattice QCD Applications on QPACE; Y. Nakamura, A. Nobile, D. Pleiter, H. Simma, T. Streuer, T. Wettig and F. Winter
• GRAPE-MP: An SIMD Accelerator Board for Multi-precision Arithmetic; Hiroshi Daisaka, Naohito Nakasato, Junichiro Makino, Fukuko Yuasa and Tadashi Ishikawa
• The performance of GRAPE-DR for dense matrix operations; Junichiro Makino, Hiroshi Daisaka, Toshiyuki Fukushige, Yutaka Sugawara, Mary Inaba and Kei Hiraki
• Development of a High-speed Eigenvalue-solver for Constant Plasma Monitoring on a Cell Cluster System; Noriyuki Kushida, Ken-ichi Fujibayashi and Hiroshi Takemiya
• SHARE: a web portal for creating and sharing executable research papers; Pieter Van Gorp, and Steffen Mazanek
• GX-Means: A model-based divide and merge algorithm for geospatial image clustering; Ranga R. Vatsavai, Christopher T. Symons, Varun Chandola and Goo Jun

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. Cellular Microscopic Pattern Recogniser – A Distributed Computational Approach for Macroscopic Event Detection in WSN; Waleed M. Alfehaid and Asad I. Khana Parallel application benchmarks and performance evaluation of the Intel Xeon 7500 family processors; Piotr Kopta, Michal Kulczewski, Krzysztof Kurowski, Tomasz Piontek, Pawel Gepner, Mariusz Puchalski and Jacek Komasa Early performance evaluation of AVX for HPC; Pawel Gepner, Victor Gamayunov and David L. Fraser * Gleipnir: A Memory Analysis Tool; Tomislav Janjusic, Krishna Kavi and Brandon Potter User-defined events for hardware performance monitoring; Shirley Moore and James Ralph * Massively parallel FPGA-based implementation of BLASTp with the two-hit method; Lars Wienbrandt, Stefan Baumgart, Jost Bissel, Florian Schatz and Manfred Schimmler * Coarse Grained Parallelized Scientific Applications on a Cost Efficient Intel Atom Based Cluster; Robin Geyer, Andy Georgi and Wolfgang E. Nagel * 10x10: A General-purpose Architectural Approach to Heterogeneity and Energy Efficiency; Andrew A. Chien, Allan Snavely and Mark Gahagan * High Performance Stencil Code Algorithms for GPGPUs; Andreas Schäfer and Dietmar Fey * Linux Cluster in Theory and Practice: A Novel Approach in Teaching Cluster Computing Based on the Intel Atom Platform; Andy Georgi, Stefan Ḧohlig, Robin Geyer and Wolfgang E. Nagel * 145 TFlops Performance on 3990 GPUs of TSUBAME 2.0 Supercomputer for an Operational Weather Prediction; Takashi Shimokawabe, Takayuki Aoki, Junichi Ishida, Kohei Kawano and Chiashi Muroi Parallel k-Means Clustering for Quantitative Ecoregion Delineation Using Large Data Sets; Jitendra Kumar, Richard T. Mills, Forrest M. Hoffman, and William W. Hargrove Lattice QCD Applications on QPACE; Y. Nakamura, A. Nobile, D. Pleiter, H. Simma, T. Streuer, T. Wettig and F. Winter GRAPE-MP: An SIMD Accelerator Board for Multi-precision Arithmetic; Hiroshi Daisaka, Naohito Nakasato, Junichiro Makino, Fukuko Yuasa and Tadashi Ishikawa The performance of GRAPE-DR for dense matrix operations; Junichiro Makino, Hiroshi Daisaka, Toshiyuki Fukushige, Yutaka Sugawara, Mary Inaba and Kei Hiraki Development of a High-speed Eigenvalue-solver for Constant Plasma Monitoring on a Cell Cluster System; Noriyuki Kushida, Ken-ichi Fujibayashi and Hiroshi Takemiya SHARE: a web portal for creating and sharing executable research papers; Pieter Van Gorp, and Steffen Mazanek GX-Means: A model-based divide and merge algorithm for geospatial image clustering; Ranga R. Vatsavai, Christopher T. Symons, Varun Chandola and Goo Jun

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/

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/

Ist das bisher am höchsten aufgelöste Bild—was ich gefunden habe—wo man mal wirklich die Schäden am AKW Fukushima sieht.

http://tomclarkblog.blogspot.com/2011/03/genie-in-bottle.html

http://farm6.static.flickr.com/5020/5525887859_e1934af238_o.jpg

Au weia … das sieht gar nicht gut aus. Die Menschen tun mir so leid da.

Ist das bisher am höchsten aufgelöste Bild---was ich gefunden habe---wo man mal wirklich die Schäden am AKW Fukushima sieht. http://tomclarkblog.blogspot.com/2011/03/genie-in-bottle.html http://farm6.static.flickr.com/5020/5525887859_e1934af238_o.jpg Au weia ... das sieht gar nicht gut aus. Die Menschen tun mir so leid da.

Beim allseits beliebten Ablenken-Vom-Für-Die-Prüfung-Lernen bin ich über dieses Video gestolpert.

Locked in a Vegas Hotel Room with a Phantom Flex from Tom Guilmette on Vimeo.

Hier der ursprüngliche Blogpost

Achja und für alle die die jetzt unbedingt so einen Camcoder wollen: Phantom Flex

Beim allseits beliebten Ablenken-Vom-Für-Die-Prüfung-Lernen bin ich über dieses Video gestolpert. Locked in a Vegas Hotel Room with a Phantom Flex from Tom Guilmette on Vimeo. Hier der ursprüngliche Blogpost Achja und für alle die die jetzt unbedingt so einen Camcoder wollen: Phantom Flex

InsideHPC hat einen neuen Artikel über den Zustand der Lustre Entwicklung bei Oracle. Sieht wohl alles noch schlechter aus als vorher gedacht:

[...] Lustre engineers have reportedly been encouraged to apply for other positions within the company.

InsideHPC hat einen neuen Artikel über den Zustand der Lustre Entwicklung bei Oracle. Sieht wohl alles noch schlechter aus als vorher gedacht: [...] Lustre engineers have reportedly been encouraged to apply for other positions within the company.