Posts by xdarma

1) Message boards : News : Rosetta's role in fighting coronavirus (Message 92321) Posted 26 Mar 2020 by xdarma Post: Pity, it sounded like a fun project. But i understand the answer after reading a bit on rosetta commons. There is another project that "folds proteins" and use GPU: https://www.gpugrid.net/ But they use CUDA, not OpenCL despite some attempts over the years to support OpenCL. If you are interested, try to contacting them. Thanks in advance.
2) Message boards : Number crunching : Rosetta@home using AVX / AVX2 ? (Message 78870) Posted 28 Sep 2015 by xdarma Post: You will certainly get what you hope for as detailed in your January 2010 article. Sorry for re-posting, but this article is dated November 2014: Intel finally agrees to pay $15 to Pentium 4 owners over AMD Athlon benchmarking shenanigans The ICC compiler now just checks the CPUID FEATURE support bits and if the feature is supported, ICC will generate the optimized code. ICC can 100% trust the CPUID FEATURE bits. For sure ICC must check CPUID, unless can't cripple non-intel cpu. The author has applied a patch to fool the software created with icc. Second the previous article, the gain (or the loss?) seem to be around 8-12%. And still so on these days. The problem is now for AMD and vendors developing software for multiple target CPU. For example, when AMD had AVX problems with Bulldozer/Interlagos, AMD recommended compiling with -mssse3 and AVOID AVX. Since the CPUID FEATURE bit was on, vendors wanting to support AVX had problems with Bulldozer silicon. Which people? Can you elaborate? I do not find anything useful. Thanks. Now you have people trying to report Intel ICC bugs because their code did not run on the AMD transistors. Intel is now prohibited by court order from generating separate bits for Intel and AMD. IMO, the only way is to separate ICC away from Intel. So ICC must be fair with other cpu makers. Maybe your job can be hit by this. But it's another story. Avoid -mavx on Interlagos/Bulldozer (middle of page) Avoid if you use ICC. If you use gcc you can optimize with -mprefer-avx-128 (on the previous page of your link). Lots of fun. Another reason not to buy intel cpu.
3) Message boards : Number crunching : R@H Scientists/Coders: An analysis of the Rosetta binaries... (Message 78416) Posted 6 Jul 2015 by xdarma Post: AVX-512 I was wrong: I did not mean AVX-512, but AVX2. APU vs AVX-512 The gpu client is a well-know desire of the rosetta crunchers. IIRC, developers have tested an OpenCL client few years ago but did not fit the needs. And I can't compare clients that doesn't exist. As a side note: I don't think nvidia can sell cpu or apu without paying royalties to intel or amd. ICC for ARM ICC does not generate ARM code... Thank you to confirm this. Most of the developers adding to the gcc optimizations have @intel.com mail address. gcc is a good compiler and lags icc by (I would guess ... a year or so) in feature development. For sure, if intel want gcc supports its cpus, it must contribute ;-) I do not think gcc "lags behind", but follow a different path. For example: supporting the ARM architecture. The option itself will tell the compiler to use the XMM registers AND if the compiler cannot vectorize the code, it can be just as fast as the 256 or 512 bit options since ..... you are doing 1 operation at a time. The developer must insure that the code parallelism is recognizable to the complier. Many times poor coding practices introduce ambiguities that prevent the generation of vector code. So, you agree with me? -mprefer-avx128 worth a test? It is VERY tough to say that binary "B" is XX% faster than binary "A" because it depends on where the program bottlenecks are. [...cut...] 2011 Sandy Bridge era AVX1 complier presentation. It talks about the icc v12 compiler and I am currently beta testing the v16. https://indico.cern.ch/event/125167/material/slides/0.pdf Thank you for informations, but I'm no longer interested on buying intel cpus. Due to unfair competition. Sorry.
4) Message boards : Number crunching : R@H Scientists/Coders: An analysis of the Rosetta binaries... (Message 78412) Posted 5 Jul 2015 by xdarma Post: If you are the developer/researcher, the question they ask is "How many systems are going to use this new feature and will it pay back the researcher effort for the port?" The Rosetta researchers have an idea about what the machine distribution looks like. I don't know if the number of AMD HSA APUs is sufficient to warrant the effort. This principle also applies in the case of AVX-512? IMO, I think there are much more APU on the market than AVX-512 enabled cpus. Even intel cpu own an integrated gpu. Not HSA-capable, but is however unused compute power. From wikipedia: The AVX instructions support both 128-bit and 256-bit SIMD. The 128-bit versions can be useful to improve old code without needing to widen the vectorization, and avoid the penalty of going from SSE to AVX, they are also faster on some early AMD implementations of AVX. This mode is sometimes known as AVX-128.[4] AVX-128 instructions that do not use YMM registers are also safe to use on operating systems without AVX-support, since AVX-support in operating systems refers to handling YMM register state.[3] Maybe the best test is to use gcc with the option -mprefer-avx128. Don't know about icc. IIRC, gcc keeps an eye on portability, not on performance. So, using icc maybe hurts the ARM version of rosetta. For sure, using icc hurts all non-intel cpu. Just some random thoughts, indeed.
5) Message boards : Number crunching : Rosetta and Android (Message 77517) Posted 28 Sep 2014 by xdarma Post: Much more sense, for example, introduce avx/avx2 extension in the rosetta code. +1 IMO, the lack of support for AVX is a loss of potential starting from today. The lack of support for ARM is (maybe) a loss from 2016. In my opinion, the development priorities should be revised. Thanks.