I would also like to agree with Nilay and Erik. There are a lot of users out there which do not have much control over what is installed on our machines and/or use server farms.
Is another options to just copy the source for protoc/libprotoc into the gem5 source tree? We could also include some Scons magic to detect if the shared libraries are installed and only use the version included with gem5 as a fallback. This certainly isn't an ideal solution, but it seems that the protobuf format is pretty well defined so the library and compiler shouldn't be changing very much. Also, from glancing at the license for Google's implementation it seems that it would be fine from that point of view. There are also a couple of other C/C++ implementations which are smaller and might be better suited to including with gem5 like http://spbc.sourceforge.net/. Thanks, Jason On Mon, Dec 10, 2012 at 10:02 AM, Steve Reinhardt <[email protected]> wrote: > 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 > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
