Steve, Jason I also run gem5 on a server farm (as well as locally), and protobuf was no more difficult (or easy) than any other gem5 dependency in my particular case. Yes, it is an additional dependency, but there are already quite a few, and hopefully the increase in inconvenience/difficulty is not noticeable for most users.
On the topic of ifdefing things away, this would not be particularly pretty as it also involves adding these guards to where ever the messages are created and used, which is currently the TrafficGen and CommMonitor (there's more in the patch pipeline, including the CPU). Thus, it's not just the stream itself. That said, of course the ifdefing can be done. We would also have to ifdef the regressions to only run certain tests if profobuf was available at compile time. If it is really essentially to adopt this change, I can add it, but it will not be pretty. The main reason why I think it is a bad choice is the added complexity in configuration management. Suddenly we have yet another version to deal with, and a pretty well hidden one. Concerning the option of adding it to gem5, yes it is 3-clause BSD so conceptually I guess that is possible. Thanks for highlighting the possibility. The various re-incarnations you mention (at least the ones I found) are all GPL or LGPL and thus no option. The difficulty here is that we would first have to build protoc, then generate the protocol files, then build gem5 (and libprotoc). It would also involve a rather unfortunate amount of code added. I'm not too enthusiastic about this route either. Morton's fork... Andreas On 10/12/2012 16:02, "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 > -- 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
