Hello Joel, thanks for your answer of course is useful. But if Mark can provide results for fewer cores it will be perfect, by the way, can anyone tell if the times are more or less linear with an increase number of cores?.
For my work it will be better to use the simlarge sets, the time is not very important because we are not interested in complete the whole benchmark. In your post you did not provide information about the completion with simlarge, is that because you did not try it, or is because it did not run?. Thanks. On Wed, Jan 7, 2009 at 7:31 PM, Joel Hestness <hestn...@cs.utexas.edu> wrote: > Hi, > Sorry for the delayed response. Since I set most of this up for a paper > submission, I have only simulated the system that we were interested in (64 > cores). Below are approximate simulation times for that system on our > Condor cluster (2 & 4 core P4 Xeons and 2 core Opterons): > > -------64 cores----------- > simsmall: simmedium: simlarge: > - blackscholes 00d05h10m 00d16h24m 01d22h39m > - bodytrack 02d05h27m 10d18h19m > - canneal 01d05h38m 03d03h57m > - dedup 00d17h14m > - facesim <- more than 20d: incomplete -> > - ferret 00d22h48m 02d23h49m > - fluidanimate 02d14h40m 02d20h03m > - freqmine 02d04h20m 04d18h53m > - vips 02d20h07m 05d15h32m > - x264 11d01h32m > -------64 cores----------- > Mark, another student in our group, might be able to give better estimates > for systems with fewer simulated cores. Hopefully this is useful, > Joel > > On Fri, Jan 2, 2009 at 11:40 PM, Eduardo Olmedo Sanchez <eolms...@gmail.com> > wrote: >> >> Hello the problem was a very bad programming that I did, I defined >> this counters to count the number of the access depending on the src: >> >> static double My_counters[9][9]; >> >> I did that for SE mode and using the flags I verify that the maximum >> src number for SE it was 9, so I put that 9 in the definition after I >> forgot to change the size and I switch to FS. In FS mode the src >> numbers are bigger so in my code it was writing in other memory space, >> and you can imagine the problem. Sorry about this stupid problem and >> thanks for the help Ali. >> >> I would like to seize the opportunity of send this email, and ask Joel >> if he can give us the estimated simulation time for the benchmarks. >> >> Thanks. >> >> On Fri, Jan 2, 2009 at 7:28 PM, Ali Saidi <sa...@umich.edu> wrote: >> > You can use GDB, that is the way most people debug issues with M5. >> > Depending on the optimization level GDB may have some issues finding >> > the exact line that you're executing but generally it works. Looking >> > at those 3 lines I don't understand how they could be causing a >> > problem. Perhaps your array is allocated incorrectly? >> > >> > Ali >> > >> > On Jan 2, 2009, at 8:16 PM, Eduardo Olmedo Sanchez wrote: >> > >> >> Hello Ali, you were right, I tried the workload in a non modified >> >> installation and it was working right, finally I traced the error to >> >> these lines that I added in the function recvTiming of bus.cc. I will >> >> post the lines that were causing the problem, because maybe it is >> >> helpful for someone in the future >> >> >> >> int foo = pkt->getDest(); >> >> if (foo == -1) foo = 8; >> >> My_counters[pkt->getSrc()][foo]++; >> >> >> >> I deleted them and now it is working fine. And another question, to >> >> debug the problem I was commenting and uncommenting the changes that I >> >> did, I would like to ask, if it is possible in this type of errors use >> >> gdb to see the lines that were causing the problem. >> >> >> >> Thanks. >> >> >> >> On Fri, Jan 2, 2009 at 3:36 PM, Ali Saidi <sa...@umich.edu> wrote: >> >>> Have you modified the simulator, particularly the memory system, in >> >>> any way? This error occurs when an object in the memory system >> >>> receives a packet it was not expecting. If you have modified the >> >>> simulator, the problem probably has to do with the modifications >> >>> you've made, if you haven't modified it then you should enable some >> >>> trace flags like Bus, Cache, etc to see what happens leading up to >> >>> this error. With that data you should be able to better understand >> >>> what is going wrong and begin to realize how to fix it. >> >>> >> >>> Ali >> >>> >> >>> On Jan 2, 2009, at 5:48 PM, Eduardo Olmedo Sanchez wrote: >> >>> >> >>>> ck, canneal, swaptions in a 4 core system, >> >>>> in Full System mode, with 4 threads and with the small workload. >> >>>> >> >>>> warn: allocating bonus target for snoop >> >>>> m5.opt: build/ALPHA_FS/mem/tport.cc:97: virtual bool >> >>>> SimpleTimingPort::recvTiming(Packet*): Assertion `pkt->isResponse()' >> >>>> failed. >> >>> >> >>> _______________________________________________ >> >>> m5-users mailing list >> >>> m5-users@m5sim.org >> >>> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users >> >>> >> >> _______________________________________________ >> >> m5-users mailing list >> >> m5-users@m5sim.org >> >> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users >> >> >> > >> > _______________________________________________ >> > m5-users mailing list >> > m5-users@m5sim.org >> > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users >> > >> _______________________________________________ >> m5-users mailing list >> m5-users@m5sim.org >> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users > > > _______________________________________________ > m5-users mailing list > m5-users@m5sim.org > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users > _______________________________________________ m5-users mailing list m5-users@m5sim.org http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
