I definitely see the value in using protobufs for traces, but I also sympathize with Nilay and Erik's arguments. In particular, many people don't use trace-driven simulation, so the protobuf dependency actually doesn't do anything for them.
I hesitate to put more work on Andreas's shoulders, but it seems like the protobuf code is reasonably well encapsulated; wouldn't it be possible with a few judiciously placed ifdefs and/or conditional compilation in SConscript files to stub out the ProtoStream class so that it compiles even without protobuf, but then generates an error if it is used? Or is there a more complex dependency that I'm overlooking? Thanks, Steve On Mon, Dec 10, 2012 at 6:37 AM, Andreas Hansson <[email protected]>wrote: > Eric, another minor note on the topic of Scientific Linux, perhaps you can > convince the sysadmin's to have a look at EPEL > (http://fedoraproject.org/wiki/EPEL) both for gperftools and protobuf. > > yum install epel-release && yum install protobuf should do the trick :-) > > Andreas > > On 10/12/2012 14:22, "Andreas Hansson" <[email protected]> wrote: > > >Hi Eric, > > > >Thanks for your input. > > > >The dependency is indeed generating some additional issues in the type of > >environments you describe, and Scientific Linux does seem to be a bit > >behind. Luckily, it should not involve more than a configure, make and > >make install to get it up and running. > > > >The big question is: what portion of the users does it affect (I would > >think most people could get away with installing the package), and are the > >benefits of protobuf large enough to warrant the additional burden? > > > >Independent of the answer to this question, we need a path forward to > >support input/output of memory traces and execution traces. The protobuf > >solution seems to be much better than any other option in solving this > >problem, in many aspects, e.g. portability, size, speed, effort. What do > >you suggest instead? > > > >Kind regards, > > > >Andreas > > > >On 10/12/2012 11:58, "Erik Tomusk" <[email protected]> wrote: > > > >>As one of the proverbial users whose experience is under discussion, > >>maybe I can butt in. > >> > >>I think it's important to realize that not everyone uses self-managed > >>machines with root access. I, for one, don't have root or access to a > >>package manager on my regular work machine (Scientific Linux 6). SL6 > >>seems to lag RHEL with package support, so as far as I can tell, > >>protobuf (and even tcmalloc) are not installed and not even available > >>( > http://ftp.scientificlinux.org/linux/scientific/6rolling/x86_64/os/Packa > >>g > >>es/) > >> > >>If I want these libraries, I need to build them and any dependencies > >>locally from tarballs or convince the admins to do it. If the admins are > >>convinced and manually build the libs (unlikely), they then need to > >>schedule reboots for all the machines in the school. Fun fun. > >> > >>I could, of course, switch to a self-managed desktop machine, except > >>that I need to regularly run lots of things on our server farm. This is > >>where it gets really interesting. Given that the farm admins have a > >>responsibility to keep the farm running for all the various groups > >>buying compute resources, there's no way they're going to manually build > >>libraries not officially supported by the distro and then support those > >>libraries for the rest of time (I already tried to convince them on > >>libperftools--no dice). Again I need to build the libraries locally and > >>then make sure that everything works across a finicky server farm, all > >>it's various nodes and whatnot. > >> > >>Since I've already invested so much time into using gem5, if another > >>dependency comes on board, I'll just have to make it work (or not > >>upgrade). I doubt a newbie would go through all this trouble, though. > >> > >>-Erik > >> > >> > >>On 09/12/12 16:09, Ali Saidi wrote: > >>> On Dec 9, 2012, at 8:53 AM, Nilay Vaish wrote: > >>> > >>>> On Sun, 9 Dec 2012, Andreas Hansson wrote: > >>>> > >>>>> May I ask why you see this as a problem? Any Unix/Linux/OSx system > >>>>>from the last 5+ years has these dependencies as packages (and I bet > >>>>>they work smoother than e.g. swig :-) > >>>>> > >>>> I doubt that this statement is true. I am using RHEL 6 and it does not > >>>>have protoc installed. I am guessing that would mean people who use > >>>>Fedora will not have it installed either. Ubuntu (12.10) has it. I > >>>>don't know about Mint or other distributions. > >>> As far as package availability protobufs is available since Fedora 16 > >>>as well as EL6. It's also available in all currently supported Ubuntu > >>>versions as well as mint and debian and just about everything else: > >>>http://pkgs.org/search/?keyword=protobuf > >>> > >>> So I think package availability is a separate concern from user > >>>experience. It's absolutely true that there would be another dependency, > >>>the question in my mind is that dependency a larger burden than we > >>>currently expect from the user and are the benefits of the library worth > >>>it? I think this is the best possible path toward being able to output > >>>memory traces, which we do seem to get a fair number of requests for on > >>>the mailing list. > >>> > >>>> This may not affect ARM, but one of the reasons why I am involved with > >>>>gem5 is that I would like people in architecture to be using the > >>>>simulator that I have contributed to. > >>> I think ARM is completely committed making gem5 successful in the > >>>broader architecture community, as evidenced by the large number of > >>>change sets with committers from ARM. > >>> > >>> Ali > >>> > >>> > >>> _______________________________________________ > >>> gem5-dev mailing list > >>> [email protected] > >>> http://m5sim.org/mailman/listinfo/gem5-dev > >>> > >> > >>-- > >>The University of Edinburgh is a charitable body, registered in > >>Scotland, with registration number SC005336. > >> > >>_______________________________________________ > >>gem5-dev mailing list > >>[email protected] > >>http://m5sim.org/mailman/listinfo/gem5-dev > >> > > > > > >-- IMPORTANT NOTICE: The contents of this email and any attachments are > >confidential and may also be privileged. If you are not the intended > >recipient, please notify the sender immediately and do not disclose the > >contents to any other person, use it for any purpose, or store or copy > >the information in any medium. Thank you. > > > >_______________________________________________ > >gem5-dev mailing list > >[email protected] > >http://m5sim.org/mailman/listinfo/gem5-dev > > > > > -- IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
