Do you have any interest in going to graduate school? Is there some research area of computer science that you really like?
If the answer to both is no, then, like others have said the school you go to is not likely to make a big difference. For people with an undergraduate degree experience is far more important than the school.
When I interview candidates that only have a bachelors degree I am more interested in finding out if they have a solid grasp of some of the important areas of Computer Science: complexity theory, and data structures. And I usually concentrate more on recent work.
But if you have any interest in exploring research areas of computer science or you want to get a Masters or PhD - then the school you go to could matter a lot.
I have no data to back up this claim but I guess that most of the professors at the second and third tier schools are not really contributing much to the current state of the art. For example if you wanted to look at advanced topics in computer networking or operating systems or optimizing compilers you really should go to a school where the professors are defining the leading edge in those areas.
I think it also matters what kind of work you ultimately want - in the industry I work in (Electronic Design Automation - basically software that helps engineers build chips) I have found that more often than not the senior technical people for most products have PhD's closely related to the key technology areas for their product.
Basically the work mentioned in that technical
report says that if you convert a table driven
LALR parser into a directly executable function
then you can get a 2.5 to 6.5 speed up for the parser.
A little background: The tables in bison and yacc generated parsers encode information about
what to do at some particular point in the parse.For example the tables could say state 20
should shift token 1 or 2 but if its token 4 then
a reduce should take place. Basically the tables
in a LALR parser are state machines.
What we showed was that if you replace the tables with executable code the resulting parser
will be faster. And the amount of code that is
generated is not too big. So the above example
could be encoded as a switch statement with case
labels for 1,2 and 4.
Of course there are lot more details that need
to be taken care of, but those are mentioned in
the paper.
I feel very safe concluding that a directly executable parser would always be faster (for
any real world language) than a
table based parser. I would similarly expect that
the recursive descent parser added to gcc would be
faster than the old table driven one.
One final note: In case anyone wants the source
code, its not ready. I've been wanting to clean it
up and release it to the world for the past 7 years now, but I've not yet managed to find the time!!
With your experience creating so many ethernet drivers do you have any opinions or suggestions for hardware makers? Aside from good documentation what makes a given hardware device easy to work with and what makes a device hard to work with?
For the past 6 years I've been a regular Purify user. During that time I've also used electric fence a few times. One of the main problems with electric fence is the increase in memory consumption your application will experience. The code I work on regularly allocates a few hundred MB of data - electric fence increased the memory consuption to the point that my application swapped so much that I was no longer productive.
Purify does increase memory consumption and it does slow down execution - but overall the penalty is moderate. I usually see at most a doubling of memory consuption under purify and at most a factor 10 slow down.
Slashdot Mirror
Do you have any interest in going to graduate
school? Is there some research area of computer
science that you really like?
If the answer to both is no, then, like others
have said the school you go to is not likely to make a big
difference. For people with an undergraduate
degree experience is far more important than the school.
When I interview candidates that only have
a bachelors degree I am more interested
in finding out if they have a solid grasp of
some of the important areas of Computer Science:
complexity theory, and data structures. And I
usually concentrate more on recent work.
But if you have any interest in exploring
research areas of computer science or you want
to get a Masters or PhD - then the school you
go to could matter a lot.
I have no data to back up this claim but I guess
that most of the professors at the second and
third tier schools are not really contributing
much to the current state of the art. For
example if you wanted to look at advanced topics
in computer networking or operating systems
or optimizing compilers you really should go to
a school where the professors are defining the
leading edge in those areas.
I think it also matters what kind of work you
ultimately want - in the industry I work in
(Electronic Design Automation - basically
software that helps engineers build chips) I
have found that more often than not
the senior technical people for most products
have PhD's closely related to the key technology
areas for their product.
I have never heard of the term recursive ascent.
Basically the work mentioned in that technical report says that if you convert a table driven LALR parser into a directly executable function then you can get a 2.5 to 6.5 speed up for the parser.
A little background: The tables in bison and yacc generated parsers encode information about what to do at some particular point in the parse.For example the tables could say state 20 should shift token 1 or 2 but if its token 4 then a reduce should take place. Basically the tables in a LALR parser are state machines.
What we showed was that if you replace the tables with executable code the resulting parser will be faster. And the amount of code that is generated is not too big. So the above example could be encoded as a switch statement with case labels for 1,2 and 4.
Of course there are lot more details that need to be taken care of, but those are mentioned in the paper.
I feel very safe concluding that a directly executable parser would always be faster (for any real world language) than a table based parser. I would similarly expect that the recursive descent parser added to gcc would be faster than the old table driven one.
One final note: In case anyone wants the source code, its not ready. I've been wanting to clean it up and release it to the world for the past 7 years now, but I've not yet managed to find the time!!
With your experience creating so many ethernet
drivers do you have any opinions or suggestions
for hardware makers? Aside from good documentation
what makes a given hardware device easy to work
with and what makes a device hard to work with?
For the past 6 years I've been a regular Purify
user. During that time I've also used electric fence a few times. One of the main problems with
electric fence is the increase in memory consumption your application will experience. The code I work on regularly allocates a few hundred MB of data - electric fence increased the memory consuption to the point that my application swapped so much that I was no longer productive.
Purify does increase memory consumption and it does slow down execution - but overall the penalty
is moderate. I usually see at most a doubling of
memory consuption under purify and at most a factor 10 slow down.