CCC- predict_opt Web Service
Nik
flags, but I cannot find the corresponding php file anywhere. Even the
send_data_to_cod.php is not opening on the web page, but i found it in
one of the directories when I installed the CCC framework. Can you
please direct me to the right source or suggest a workaround for this?
Grigori Fursin
I am going on vacations today and will not have good access to the Internet
so will check it out with Abdul when I am back. We want to write a small
guide on milepost-gcc before the HiPEAC conference anyway (since there will
be a small tutorial on cTuning) so we will try to check it out and will
get back in touch ...
Cheers,
Grigori
> --
>
> You received this message because you are subscribed to the Google Groups "ctuning-
> discussions" group.
> To post to this group, send email to ctuning-d...@googlegroups.com.
> To unsubscribe from this group, send email to ctuning-
> discussions...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/ctuning-
> discussions?hl=en.
Nik
Thank you for your reply. I have managed to write a php script that is
able to access the cPredict Web Service. One of the problems that I
was facing was that we also need to send the COMPILER_ID in the POST
variables, which has not been mentioned on the Database access page in
the predict_opt section. I guess it will help if you can add it there.
I also saw that it was written that you are looking to optimize the
passes in the future and not just the flags, so I wanted to know
whether that part has been done yet? And isn't this the one major add-
on to ICI 2.0 from its previous version, that it can modify the
compiler passes as well?
Grigori Fursin
Happy New Year!
I am now back from vacations and this week have a deadline to finish a paper,
but plan to check out MILEPOST GCC and web-services next week. By the way, I
just found the glitch that the latest version of web-service returns the same
flags for all programs while the on-line predictors works correctly - need to
check it out. Also, we are now verifying results on several platforms and
converting flags to passes (Abdul and Yuri (in CC) are working on that) so we
will be happy to discuss that with you to see if this will be also applicable to
MOZILLA builds ...
Will keep in touch,
Grigori
P.S. By the way, sorry for non-intuitive documentation on MILEPOST GCC and
cTuning (I saw your posts here that you still managed to get some of the stuff
working ;) : http://nikhilkapur.blogspot.com/search/label/Mozilla) - the whole
projects were awfully time consuming and I just couldn't work more than 24/7
to finish it all ;) - I hope to be able to update it with the help of my colleagues
this month ...
-----Original Message-----
From: ctuning-d...@googlegroups.com [mailto:ctuning-d...@googlegroups.com] On Behalf
Of Nik
--
You received this message because you are subscribed to the Google Groups "ctuning-discussions"
group.
To post to this group, send email to ctuning-d...@googlegroups.com.
To unsubscribe from this group, send email to ctuning-discuss...@googlegroups.com.
Grigori Fursin
* methodology for performance evaluation: I tried to optimize Firefox a few years ago and noticed
that major improvement may come not from Firefox code itself but from libraries such as jpeg
decoding - do you consider the whole Firefox or only specific parts of it?.. Also, do you use
oprofile?.. Which datasets you use (here I mean we need to agree to run firefox on some given pages
with the same graphics, etc).
* stability of timing across runs
* compilation time - there can be slow downs using MILEPOST GCC feature extractor though there can
be some gains from predicting lower optimization levels on codes that do not need optimizations. I
didn't check it on very large codes so it will be interesting to see what is happening. Actually, it
may also be interesting to semi-manually use Collective Optimization Database directly to find best
optimizations found for a given architecture for
similar programs ...
* correctness of optimizations: we think not to select fully randomly flags anymore but have a proxy
where each randomly generated combination/sequence of flags/passes is tested on a GCC validation
suite
and then added to a verified database of combinations of optimizations to evaluate. This is
particularly
important for production codes!..
Cheers,
Grigori
-----Original Message-----
From: ctuning-d...@googlegroups.com [mailto:ctuning-d...@googlegroups.com] On Behalf
Of Nik
Sent: Tuesday, December 22, 2009 4:47 PM
To: ctuning-discussions
Subject: Re: CCC- predict_opt Web Service
--
You received this message because you are subscribed to the Google Groups "ctuning-discussions"
group.
To post to this group, send email to ctuning-d...@googlegroups.com.
To unsubscribe from this group, send email to ctuning-discuss...@googlegroups.com.
Nik
Thank you for your replies. I'll mention here that right now no work
regarding integrating Milepost into Mozilla code has been done.. I am
only a student so its taking me time to learn :) and also I do not
know much about the Mozilla codebase, but yes I am moving forward :).
We do not plan to do it for the whole of firefox right now. I am
starting with a smaller module first and plan to move from module to
module. I had started with Spidermonkey, the jscript engine, but later
we realised that it uses a c++ compiler for most of the part and as
milepost has not been tested yet for c++, I'll have to drop it for now
and concentrate on the parts which are C-only. There are a few which
humph, ted have told me about: nspr, nss, libjpeg, cairo but according
to ted, cairo and libjpeg are already highly optimised. So on there
suggestion I'll start with nspr and see how that turns out and post
details of progress about the same. Right now, I'll just try to
integrate Milepost into the build system and after that I'll bother
you regarding the optimizations achieved, profiling scenarios and the
datasets we'll use :)..
Grigori Fursin
Good luck and will keep in touch!
We will tell you if we have progress/updates from our side within next few weeks ...
Cheers,
Grigori
-----Original Message-----
From: ctuning-d...@googlegroups.com [mailto:ctuning-d...@googlegroups.com] On Behalf
Of Nik
Sent: Tuesday, January 05, 2010 12:43 PM
To: ctuning-discussions
Subject: Re: CCC- predict_opt Web Service
--
Nik
There are a few questions that I have..
1. The plugins that I am currently using do not attach a compiled-file-
name to the files that are created, so two files with the same
function name will end up writing/reading to the same file for
features, passes etc.. Is there any workaround for this? For eg. two
files myfile1.c and myfile2.c will create the same file:
ici_passes_function.main.txt if they both have "main" function. Is
there a way to change this files name to
ici_passes_myfile1_function.main.txt and
ici_passes_myfile2_function.main.txt?
2. Is it possible to extract the static features from a group of files
directly instead of a file to file basis.. For eg. a plugin that
somehow extracts features from the whole module of nspr instead of
working on each file in it? As people at mozilla are telling me that
if we try to tune each file in a module it won't be very scalable as
it will take too much time.
Thanks for your help..
Grigori Fursin
>1. The plugins that I am currently using do not attach a compiled-file-
>name to the files that are created, so two files with the same
>function name will end up writing/reading to the same file for
>features, passes etc.. Is there any workaround for this? For eg. two
>files myfile1.c and myfile2.c will create the same file:
>ici_passes_function.main.txt if they both have "main" function. Is
>there a way to change this files name to
>ici_passes_myfile1_function.main.txt and
>ici_passes_myfile2_function.main.txt?
Good point. I saw such potential problems and that's why we decided
to use a global XML file for the ICI. My ICT colleagues implemented
that this summer but it is still not released ... Otherwise, I think
you should be able to update the plugin that records/loads plugin
and add a source file name (normally, we should have already added a support
to obtain filename of the compiled source in the version of ICI you are
using)
>2. Is it possible to extract the static features from a group of files
>directly instead of a file to file basis.. For eg. a plugin that
>somehow extracts features from the whole module of nspr instead of
>working on each file in it? As people at mozilla are telling me that
>if we try to tune each file in a module it won't be very scalable as
>it will take too much time.
Another good point. Yes, it is possible - you should prepare a text
file with filename/functions to process and then modify load/store plugin
to extract features only for those filenames/functions (it shouldn't
be too difficult).
Again, we planned to do this control through XML but it's not finished
yet, so you can update the old plugin yourself for now ;) ...
Cheers,
Grigori
Nik
get stuck on something.. I had one more question to ask:
There are environment variables which we need to export for the
plugins to work. Normally, I was using source myscript.sh in bash to
run this script which would export the vars to the current shell. A
simple ./myscript.sh was not able to do that. Now I have to do the
same work in a makefile, so is it possible to do this somehow. I tried
a lot of things but nothing seemed to work. Maybe you can suggest a
workaround? Basically I have created an additional rule in the mozilla
makefile:
milepostbuild:
#set env vars here for extracting passes
make
#set env vars here for extracting features
make
Can you suggest something that will help me set these environment
variables here?
Yuri Kashnikoff
> Ohk, thanks.. I'll try to do these on my own and will contact you if I
> get stuck on something.. I had one more question to ask:
>
> There are environment variables which we need to export for the
> plugins to work. Normally, I was using source myscript.sh in bash to
> run this script which would export the vars to the current shell. A
> simple ./myscript.sh was not able to do that.
This is because of the scope of the variables you are trying to export.
You simply need to open your terminal and write something like:
export VAR1=VAL2
export VAR2=VAL2
...
And after that in the SAME terminal session you should run all what you need.
As a trick you can add a section with exports in your ~/.bash_profile
(or ~/.bashrc) file.
Remember that bash uses environment -
http://www.gnu.org/software/bash/manual/bashref.html#Environment
> Now I have to do the
> same work in a makefile, so is it possible to do this somehow. I tried
> a lot of things but nothing seemed to work. Maybe you can suggest a
> workaround? Basically I have created an additional rule in the mozilla
> makefile:
>
> milepostbuild:
> #set env vars here for extracting passes
> make
> #set env vars here for extracting features
> make
>
> Can you suggest something that will help me set these environment
> variables here?
Do not hesitate to ask!
I will also try to help you with your research.
Nik
Thank you for your reply.
> You simply need to open your terminal and write something like:
> export VAR1=VAL2
> export VAR2=VAL2
> ...
> And after that in the SAME terminal session you should run all what you need.
I have been doing as you have said till now, while I was working with
small programs of my own. Now, I am trying to integrate Milepost into
Mozilla builds. Right now, I am trying to make two passes on the whole
code of nspr (a small C module in Mozilla) and on the first pass
extracting the compiler passes and on the second pass extracting the
corresponding features. For this, I need to set some environment
variables between these two passes (indicated in my previous post). At
that time I am inside the makefile and I cannot use export over there
as it does not update the current shell. Also I tried putting these
exports inside a script and tried running the script using "source"
from inside the makefile but even that did not work. For this I need
some ideas. I can perhaps write a script which calls make twice
exporting the env vars whenever needed, but it will not be very
elegant as instead of using "make milepostbuild" the user will have to
call that script which will then call make on its own. So I need a
solution for exporting these variables from inside the makefile
itself.
> As a trick you can add a section with exports in your ~/.bash_profile
> (or ~/.bashrc) file.
Again this is OK for the initial export of variables, but cannot be
used in between make's passes.
@Grigori:
>2. Is it possible to extract the static features from a group of files
>directly instead of a file to file basis..
>>Another good point. Yes, it is possible - you should prepare a text
>>file with filename/functions to process and then modify load/store plugin
>>to extract features only for those filenames/functions (it shouldn't
>>be too difficult).
Well this will help a little, in the sense that we won't need to make
three passes on files which we don't want compiled using milepost. But
what I actually meant was something that would be able to extract
features from a whole module in one go and which would (maybe) predict
flags for the whole module instead of for each file. Because if we do
these steps for each file it involves a lot of overhead of requesting
the web service each time, etc.
Yuriy Kashnikov
> So I need a solution for exporting these variables from inside the makefile itself.
OK. You can use "export" command for this purpose. But remember that
only variables existed in environment of the initial make process
would be exported to all sub-processes. So, just initialize all
variables before running make with some dummy values and after that
they could be redefined and exported for sub-process inside the
Makefile.
Good luck!
Yuriy
Nik
There are a few things that I would like your help on:
1. I see that ICI_PROG_FEAT_PASS is to be set to "fre". Can you tell
me its significance. Because I think (I am not sure) that when one
compiles with -O only, fre does not come up in the executed passes and
hence the feature extractor does not work properly. Is it ok if I use
some other pass in this environment variable instead of fre?
2. I asked this a couple of posts back. Can you please help?
>Well this will help a little, in the sense that we won't need to make
>three passes on files which we don't want compiled using milepost. But
>what I actually meant was something that would be able to extract
>features from a whole module in one go and which would (maybe) predict
>flags for the whole module instead of for each file. Because if we do
>these steps for each file it involves a lot of overhead of requesting
>the web service each time, etc.
3. Did you get time to check the predict-opt web service because as
you mentioned it is returning the same set of optimizations every
time. Also, which database can I use for predictions? cod_opt_cases?
And if that, can you give me the login please?
@Yuri: Thanks for your tip. A normal export did not work for me, but
adding VAR=VAL while calling submake did the trick.
Nik
Can you people please check the predict-opt web service. Because I
believe I have finally integrated the whole thing into nspr of
Mozilla, but to make sure of that I want proper predicted
optimizations instead of the same results each time. I can't start
testing the improvements unless this is done. I appreciate your time
spent in this. Thanks a lot..
Nik
Grigori Fursin
We will do our best to check it this week and we will tell you when it's done ...
Take care,
Grigori
-----Original Message-----
From: ctuning-d...@googlegroups.com [mailto:ctuning-d...@googlegroups.com] On Behalf
Of Nik
Sent: Sunday, January 17, 2010 8:49 PM
To: ctuning-discussions
Subject: Re: CCC- predict_opt Web Service
Yuri Kashnikoff
We are working on the web service issue right now and hopefully
everything will work very soon.
There is also another issue we are working on right now and in which
you probably would be interested in -- correctness.
Unfortunately, some of the combinations could lead to the crash of the
compiler or crash of the produced binary.
In the theory this should never happen but practically could be so.
Actually, we found potentially dangerous cases and working on these
issues to exclude them from consideration as a working combinations.
Additionally, we have already achieved a 20% of speedup for the
BerekeleyDB on the Oracle official performance benchmark. And this is
just our first attempt to optimize it. This promises to be already a
good achievement.
We will keep in touch.
---
Yuriy
Grigori Fursin
- the officially released one (4.4.0) or you tried to port it to
some other version 4.4.x?.. Which version do MOZILLA guys use at
the moment?
I am asking because Joern Renneke mentioned that latest ICI should support C++
so at some point we will try to release a new version that will support
C++ as well (but as usual it will take some time ;) ) ...
Cheers,
Grigori
-----Original Message-----
From: ctuning-d...@googlegroups.com [mailto:ctuning-d...@googlegroups.com] On Behalf
Of Yuri Kashnikoff
Sent: Monday, January 18, 2010 7:12 PM
To: ctuning-d...@googlegroups.com
Subject: Re: CCC- predict_opt Web Service
Nik
@Grigori
I am using 4.4.0.. And when you ask about the mozilla people are you
talking about normal gcc? I am not sure which one they are using for
their builds, but we can use 4+ i guess generally.. Great to hear
about the C++ part.. If that is done, we can try and optimize
spidermonkey and that will be quite helpful as we can also measure the
perf boost easily using SunSpider..
Currently, I have integrated milepost into nspr and I have now moved
on to oggvorbis which is also in C..
@Yuriy
Thanks for taking a look at the web service. Please let me know
whenever it gets resolved.
I'll keep in mind the crashing tip.
And great to hear about the optimization of berkeleyDB,
congratulations :).. I hope I'll be able to bring out similar results
in Mozilla :)..