search for: gemme

On 05/17/2016 01:47 PM, Michael Kruse wrote: > 2016-05-16 19:52 GMT+02:00 Roman Gareev <gareevroman at gmail.com>: >> Hi Tobias, >> >> could we use information about memory accesses of a SCoP statement and >> def-use chains to determine statements, which don’t contain matrix >> multiplication of the following form? > > Assuming s/don't/do you want

Hi Tobias, could we use information about memory accesses of a SCoP statement and def-use chains to determine statements, which don’t contain matrix multiplication of the following form? for (int i = 0; i < Upper Bound1; i++) for (int j = 0; j < Upper Bound2; j++) for (int k = 0; k < Upper Bound3; j++) C[i][j] += A[i][k] * B[k][j] We could probably check that memory access

salut Alex, je ne peut pas télécharger wxruby-1.9.2 avec rubygems. J''avait wxruby-1.9.0, mais j''ai fait une restauration complète de mon pc hier. J''ai la version 0.9.4 de ruby gems. J''ai un message d''erreur <openURI::HTTPerror> quand je veut installer wxruby-1.9.2. merci _______________________________________________ wxruby-users mailing list

now i am working in a rails project version 1.2.3 but i like to work in rails 2.1.1 i thing by freexe the 1.2.3 gemm into vendor will solve the problem but i have 35 plugin in my project(which is version 1.2.3) so i worried about freezeing old gem into vendeor any help appreciated? thanks -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You

Dear all, I would like to submit an issue that we are facing. Indeed, in our environment, we are optimizing the R code to speed up some mathematical calculations as matrix products using the INTEL libraries ( MKL) ( https://software.intel.com/en-us/mkl ) With the last version of the MKL libraries Intel 2018, we are facing to an issue with *all INTERNAL command* that are executing in R.

At 2013-08-12 01:18:30,"Tobias Grosser" <tobias at grosser.es> wrote: >On 08/10/2013 06:59 PM, Star Tan wrote: >> Hi all, >> >> I have evaluated Polly's performance on LLVM test-suite with latest LLVM (r188054) and Polly (r187981).  Results can be viewed on: http://188.40.87.11:8000. > >Hi Star Tan, > >thanks for the update. >

Hi all, It seems that Polly's code generation can leads to high compile-time overhead, especially for PolyBench applications such as 2mm, 3mm, gemm, syrk, etc. Some basic evaluation and analysis for Polly's code generation can be referred to http://llvm.org/bugs/show_bug.cgi?id=16898. Currently, we can choose to run -polly-code-generator=cloog or -polly-code-generator=isl for code

Hello all, The performance comparison between Polly's Cloog and ISL code generator is posted on http://188.40.87.11:8000/db_default/v4/nts/59?compare_to=58&baseline=58 It seems their execution-time performance are comparable: Performance Regressions - Execution Time  (ISL over Cloog) MultiSource/Benchmarks/TSVC/ControlFlow-flt/ControlFlow-flt 8.49%

On Mon, 15 Jan 2018 22:44:45 +0100, Tobias Grosser via llvm-dev wrote: <snip> > * How stable/fast/… is Polly today > * We build all of AOSP with rather restrictive compile-time limits > * Bootstrapping time of clang is regressed by 6% (at most) > * Removal of scalar dependences is today very generic and must be > sped up in the future > * Polly still

...I want to install wxruby-1.9.2. Please Reply (Me): [French:] Salut Sebastien, Il semble que RubyGems est d''avoir avec les erreurs d''indexation et le téléchargement de wxRuby. Elle sera mieux pour vous de télécharger wxRuby - 1.9.2 de Rubyforge page, et l''installer si gemme. Ceci devrait vous permettre d''installer wxRuby 1.9.2. Laters, Mario Steele [English:] Hello Sebastien, It seems that RubyGems is to have mistakes with the indexing and downloading wxRuby. It will be better for you to download wxRuby - 1.9.2 of Rubyforge page, and install it if gem....

Sorry for not responding earlier. On 05/20/2016 03:05 PM, Roman Gareev wrote: > Thank you very much for the advices! I could probably try to avoid > using of nonhardware prefetching in the project, if Tobias doesn’t > disagree with it. My understanding is that prefetching isn’t used > explicitly in [1] and, according to [2], in some cases 90% of the > turbo boost peak of the

2016-05-19 21:45 GMT+05:00 4lbert C0hen <4lbert.h.c0hen at gmail.com>: > One short note. I would advise against spending time on prefetching for x86. > Recent hardware prefetchers are amazingly good at strided accesses in > single-threaded code. Caution: this is not based on objective/published > data, but on personal experience. > > There are open challenges in

[add subject] Dear LLVM community, hope all of you had a good start into 2018 and a quiet branching of LLVM 6.0. With the latest LLVM release out of the way and a longer development phase starting, we would like to restart the process of including Polly and isl into core LLVM to bring changes in early on before the next LLVM release. Short summary: * Today Polly is already part of each LLVM

On 09/01/2013 08:02 PM, Star Tan wrote: > Hi all, > > > It seems that Polly's code generation can leads to high compile-time overhead, especially for PolyBench applications such as 2mm, 3mm, gemm, syrk, etc. Some basic evaluation and analysis for Polly's code generation can be referred to http://llvm.org/bugs/show_bug.cgi?id=16898. > > > Currently, we can choose to

At 2013-09-02 17:05:52,"Tobias Grosser" <tobias at grosser.es> wrote: >On 09/01/2013 08:02 PM, Star Tan wrote: >> Hi all, >> >> >> It seems that Polly's code generation can leads to high compile-time overhead, especially for PolyBench applications such as 2mm, 3mm, gemm, syrk, etc. Some basic evaluation and analysis for Polly's code generation

Dear LLVM community, hope all of you had a good start into 2018 and a quiet branching of LLVM 6.0. With the latest LLVM release out of the way and a longer development phase starting, we would like to restart the process of including Polly and isl into core LLVM to bring changes in early on before the next LLVM release. Short summary: * Today Polly is already part of each LLVM release (and

On 08/10/2013 06:59 PM, Star Tan wrote: > Hi all, > > I have evaluated Polly's performance on LLVM test-suite with latest LLVM (r188054) and Polly (r187981). Results can be viewed on: http://188.40.87.11:8000. Hi Star Tan, thanks for the update. > There are mainly five new tests and each test is run with 10 samples: > clang (run id = 27): clang -O3 > pollyBasic (run id =

On 09/08/2013 11:46 AM, Star Tan wrote: > At 2013-09-02 17:05:52,"Tobias Grosser" <tobias at grosser.es> wrote: > >> On 09/01/2013 08:02 PM, Star Tan wrote: >>> Hi all, >>> >>> >>> It seems that Polly's code generation can leads to high compile-time overhead, especially for PolyBench applications such as 2mm, 3mm, gemm, syrk, etc.

At 2013-09-09 05:02:14,"Tobias Grosser" <tobias at grosser.es> wrote: >On 09/08/2013 11:46 AM, Star Tan wrote: >> At 2013-09-02 17:05:52,"Tobias Grosser" <tobias at grosser.es> wrote: >> >>> On 09/01/2013 08:02 PM, Star Tan wrote: >>>> Hi all, >>>> >>>> >>>> It seems that Polly's code

On 05/03/2013 11:39 AM, Star Tan wrote: > Dear Tobias, > > > Thank you very much for your very helpful advice. > > > Yes, -debug-pass and -time-passes are two very useful and powerful > options when evaluating the compile-time of each compiler pass. They > are exactly what I need! With these options, I can step into details > of the compile-time overhead of each pass.