Re: blog: Overlooked Essentials for Optimizing Code (Software
On 11/11/2010 11:50, lurker wrote: ruben niemann Wrote: Diego Cano Lagneaux Wrote: Well, I think a simple look at the real world is enough to agree that you need several years of experience and good skills. Moreover, my personal experience is that it's easier to get a job (and therefore the much needed working experience) when you have a 3-year degree than a 5-year one, at least in Spain: I've been told at many job interviews that I was 'overqualified' (I didn't care about that, just wanted to work, but they did) Same happened to me. I've MSc in computer engineering from a technical university. I began my PhD studies (pattern recognition and computer vision), but put those on hold after the first year because it seemed there isn't much non-academic work on that field and because of other more urgent issues. Four years after getting my MSc I'm still writing user interface html / css / javascript / php in a small enterprise. Hoping to see D or some strongly typed language in use soon. I'm one of the techies running the infrastructure, I should have studied marketing / management if I wanted to go up in the organization and earn more. It's usually your own fault if you don't get promotions. My career started with WAP/XHTML/CSS, J2EE, Tapestry, Struts, then Stripes, Spring, Hibernate, jQuery, and few others. Due to my lack of small talk social skills, I was frist moved from client interface and trendy things to the backend coding and testing, later began doing sysadmin work at the same company. My working area is in the basement floor near a tightly locked and cooled hall full of servers. It's pretty cold here, I rarely see people (too lazy to climb upstairs to fetch a cup of coffee so I brought my own espresso coffee maker here) and when I do, they're angry because somefoobar doesn't work again. So lurker is actually also your job description? :P -- Bruno Medeiros - Software Engineer
Re: blog: Overlooked Essentials for Optimizing Code (Software Engineering degrees)
[ ... ] Well, I am not sure you got what I meant. What I said is not that engineers will never code or won't have to after a couple years. The idea is more that engineers will be able to have people with different skills to manage, or to work closely with, so they'll have to know many fields to understand the whole thing. And I was not talking specifically about computers, but about all kinds of engineering. Engineering is about understanding and developping projects as a whole, which doesn't exclude working also on the details. Of course, many engineers may end doing different things, which is another advantage of the generalist approach. I'm actually doing websites now! Yeah, I wasn't accusing you of sharing that viewpoint, at least not in the same way that those students I mentioned in my post. But you do agree that in the case of Software Engineers at least, you will lead a big project only after you have several years of experience (more or less depending on how big the project is), and even so, only if you are skilled enough? But more importantly, you don't need to lead over anyone to be a Software Engineer, even a good one. In other words, it's not very analogous to say, civil engineering. Well, I think a simple look at the real world is enough to agree that you need several years of experience and good skills. Moreover, my personal experience is that it's easier to get a job (and therefore the much needed working experience) when you have a 3-year degree than a 5-year one, at least in Spain: I've been told at many job interviews that I was 'overqualified' (I didn't care about that, just wanted to work, but they did) However, I still think all engineerings* are conceptually the same: you need all qualifications for large projects (which doesn't exclude smaller ones) in your field; given enough time, you have to be able to do everything. Of course, for anything larger than quite small, you'll need a team. It's just that Civil Engineering usually deals with large projects, and most Software projects are smaller. I insist: this is conceptually. Real world is most Computer Engineers never get to do engineering work, and almost all spend their first years not being engineers. *To me, engineering is the process of creating mechanisms, from planification to physical result.
Re: blog: Overlooked Essentials for Optimizing Code (Software
Diego Cano Lagneaux Wrote: Well, I think a simple look at the real world is enough to agree that you need several years of experience and good skills. Moreover, my personal experience is that it's easier to get a job (and therefore the much needed working experience) when you have a 3-year degree than a 5-year one, at least in Spain: I've been told at many job interviews that I was 'overqualified' (I didn't care about that, just wanted to work, but they did) Same happened to me. I've MSc in computer engineering from a technical university. I began my PhD studies (pattern recognition and computer vision), but put those on hold after the first year because it seemed there isn't much non-academic work on that field and because of other more urgent issues. Four years after getting my MSc I'm still writing user interface html / css / javascript / php in a small enterprise. Hoping to see D or some strongly typed language in use soon. I'm one of the techies running the infrastructure, I should have studied marketing / management if I wanted to go up in the organization and earn more. *To me, engineering is the process of creating mechanisms, from planification to physical result. That's my view of the engineering, too.
Re: blog: Overlooked Essentials for Optimizing Code (Software
ruben niemann Wrote: Diego Cano Lagneaux Wrote: Well, I think a simple look at the real world is enough to agree that you need several years of experience and good skills. Moreover, my personal experience is that it's easier to get a job (and therefore the much needed working experience) when you have a 3-year degree than a 5-year one, at least in Spain: I've been told at many job interviews that I was 'overqualified' (I didn't care about that, just wanted to work, but they did) Same happened to me. I've MSc in computer engineering from a technical university. I began my PhD studies (pattern recognition and computer vision), but put those on hold after the first year because it seemed there isn't much non-academic work on that field and because of other more urgent issues. Four years after getting my MSc I'm still writing user interface html / css / javascript / php in a small enterprise. Hoping to see D or some strongly typed language in use soon. I'm one of the techies running the infrastructure, I should have studied marketing / management if I wanted to go up in the organization and earn more. It's usually your own fault if you don't get promotions. My career started with WAP/XHTML/CSS, J2EE, Tapestry, Struts, then Stripes, Spring, Hibernate, jQuery, and few others. Due to my lack of small talk social skills, I was frist moved from client interface and trendy things to the backend coding and testing, later began doing sysadmin work at the same company. My working area is in the basement floor near a tightly locked and cooled hall full of servers. It's pretty cold here, I rarely see people (too lazy to climb upstairs to fetch a cup of coffee so I brought my own espresso coffee maker here) and when I do, they're angry because some foobar doesn't work again.
Re: blog: Overlooked Essentials for Optimizing Code
On 02/11/2010 04:25, BCS wrote: Hello Bruno, On 31/10/2010 05:35, BCS wrote: Hello Bruno, Which degree did 'Software engineers' take then? You know, that's one thing that kinda irks me: Why is it called 'Software engineers' when I've never seen engineering taught in a CS course (not to be confused with real computer engineering courses that are a lot more like EE than CS). What are you referring to when you say called 'Software engineers' ? The people who write software, or the college degrees/programs? I didn't quite get it. I've never seen the details of a software engineering program so I can't say much on that, but my current job title is software engineer and I know *I'm* not doing engineering. I don't think you understood my question. You said Why is it called 'Software engineers', and I was asking what you meant by it. Were you referring to the people, or to the degrees? The most direct example of this I know of is in The Pragmatic Programmer: Item 18 is estimate to avoid surprises and then goes on to describe how to do that. Well, if programming were taught as an engineering discipline, that would be a pointless (if not insulting) comment because what it is advocating is so fundamental to engineering that it goes without saying. What do you mean if programming were taught as an engineering discipline ? I'm saying that programming is *not* taught or practiced as an engineering discipline (Ok, maybe the DOD, DOE and NASA do). Furthermore, I'm presenting the fact that item 18 needs stating as evidence supported to support my assertion and supporting that with the assertion that any practitioner of an engineering discipline wouldn't need to be told about item 18. Ehh? needs stating as evidence supported to support my assertion and supporting that with the assertion that ?? To be totally clear, I'm not saying that software development should be done as an engineering process, but that the standard practices (and job title) of today shouldn't claim to be engineering. What is engineering to you then? -- Bruno Medeiros - Software Engineer
Re: blog: Overlooked Essentials for Optimizing Code (Software Engineering degrees)
On 01/11/2010 22:58, Diego Cano Lagneaux wrote: In most Europe, Engineering is always a 5 years (masters) degree, oriented to big project developers who'll (supposedly) lead teams. I've heard it's different in the Anglosaxon systems. Whoa! :o Shit, I'm going to go on a big tangent here, but I'm very surprised to again hear that notion that the 5 year CS/Engineering degrees in Europe are for big project developers who'll (supposedly) lead teams.. In my university (which, btw, is widely regarded as the best technical/engineering school in Portugal), that idea was often mentioned by some of the senior students in my degree. The details of their opinions varied, but generally some of them seemed to think that our graduates would soon become project managers and/or software architects in the workforce, whereas most of the programming and grunt work would be left to the trolhas: the lowly developers who took the subprime 3 year practical courses in other universities/polytechnics. (Trolha is Portuguese slang for a bricklayer, or also any guy who does construction work... see the metaphor here?) Obviously I found this whole idea to be complete nonsense. Not that I didn't agree that the CS/E graduates from our degree were much better (on average) than the graduates from those 3 or 4 year CS/E courses, but rather the stupid notion that it would be perfectly fine (and ideal) for a software team to have one or two good software engineers as project leaders/managers/architects, and the rest to be code monkeys... These seniors students were completely blind to the importance of having the majority of your developers be good, smart developers (even if junior ones). One or two of such seniors even went so far as to comment that programming itself was a lowly task, for trolhas only... we the Engineers might program in the first 2-3 years after entering the workplace, but we would gradually move to a architure/design role in enterprise and soon would not need program anymore... [end of quote, and you could feel in these comments how much this guy really disliked programming... ] Man, my eyes went cartoonishly wide open when I read this. How incredibly deluded this guy was... :S But the whole surprising thing is, I wasn't expecting this kind of attitude in other countries, I thought this was somewhat isolated in Portugal... a mix of personal delusion (derived from the fact that actually these guys sucked at programming, or anything else useful), combined with a still lingering non-meritocratic class arrogance in Portuguese society. Nobility may be long gone, but there are a lot of people in Portugal who like to put themselves about other people, and having a degree (especially with title-conferring degrees, which engineering degrees are btw) is a very common excuse for people trying to make themselves look superior, (even if their degree was crappy, or they sucked at it). Well, I am not sure you got what I meant. What I said is not that engineers will never code or won't have to after a couple years. The idea is more that engineers will be able to have people with different skills to manage, or to work closely with, so they'll have to know many fields to understand the whole thing. And I was not talking specifically about computers, but about all kinds of engineering. Engineering is about understanding and developping projects as a whole, which doesn't exclude working also on the details. Of course, many engineers may end doing different things, which is another advantage of the generalist approach. I'm actually doing websites now! Yeah, I wasn't accusing you of sharing that viewpoint, at least not in the same way that those students I mentioned in my post. But you do agree that in the case of Software Engineers at least, you will lead a big project only after you have several years of experience (more or less depending on how big the project is), and even so, only if you are skilled enough? But more importantly, you don't need to lead over anyone to be a Software Engineer, even a good one. In other words, it's not very analogous to say, civil engineering. -- Bruno Medeiros - Software Engineer
Re: blog: Overlooked Essentials for Optimizing Code
On 31/10/2010 05:35, BCS wrote: Hello Bruno, Which degree did 'Software engineers' take then? You know, that's one thing that kinda irks me: Why is it called 'Software engineers' when I've never seen engineering taught in a CS course (not to be confused with real computer engineering courses that are a lot more like EE than CS). What are you referring to when you say called 'Software engineers' ? The people who write software, or the college degrees/programs? I didn't quite get it. The most direct example of this I know of is in The Pragmatic Programmer: Item 18 is estimate to avoid surprises and then goes on to describe how to do that. Well, if programming were taught as an engineering discipline, that would be a pointless (if not insulting) comment because what it is advocating is so fundamental to engineering that it goes without saying. What do you mean if programming were taught as an engineering discipline ? -- Bruno Medeiros - Software Engineer
Re: blog: Overlooked Essentials for Optimizing Code (Software Engineering degrees)
On 25/10/2010 23:09, Diego Cano Lagneaux wrote: En Mon, 25 Oct 2010 13:22:02 +0200, Bruno Medeiros brunodomedeiros+s...@com.gmail escribió: On 22/10/2010 15:56, Diego Cano Lagneaux wrote: Well, you think wrongly. :) If you look at the top universities worldwide, the majority of them have only one computer programming undergraduate degree. Sometimes it is called Computer Science (typical in the US), other times it is called Computer Engineering, Informatics Engineering, Software Engineering, Informatics Science or something like that (typical in Europe), but despite the different names they are essentially the same: courses designed to _teach and educate future software engineers_. I must nuance: as an European* Informatics (and Applied Maths**) engineer, I can say this degree is not 'Software engineer' but indeed 'whole computer engineer' as we studied both software and hardware, to the point of building a complete (simulated) processor. Furthermore, I can't recall they told us about profiling tools, but it was 10 years ago and I skiped a few classes, so it means nothing. Which degree did 'Software engineers' take then? Well, depends of what you mean by Software engineer. They could take a 3 years 'informatics' degree, which is not an engineering degree (even if it's called 'technical engineering in Spain) but is perfect for coders, or take the full 'informatics engineering' and just specialize later (or forget everything they don't need), for a more general and advanced degree. Yeah, I meant the longer, more comprehensive degree (which like you said is usually 5 years long in continental Europe). But yeah, you are right, these courses are not just for software engineers, but also other related areas (computer/hardware engineering, IT/systems administration, MIS). That was the case in my university, one would specialize in one of these areas in the last 2 years (of the 5 year degree program). In most Europe, Engineering is always a 5 years (masters) degree, oriented to big project developers who'll (supposedly) lead teams. I've heard it's different in the Anglosaxon systems. Whoa! :o Shit, I'm going to go on a big tangent here, but I'm very surprised to again hear that notion that the 5 year CS/Engineering degrees in Europe are for big project developers who'll (supposedly) lead teams.. In my university (which, btw, is widely regarded as the best technical/engineering school in Portugal), that idea was often mentioned by some of the senior students in my degree. The details of their opinions varied, but generally some of them seemed to think that our graduates would soon become project managers and/or software architects in the workforce, whereas most of the programming and grunt work would be left to the trolhas: the lowly developers who took the subprime 3 year practical courses in other universities/polytechnics. (Trolha is Portuguese slang for a bricklayer, or also any guy who does construction work... see the metaphor here?) Obviously I found this whole idea to be complete nonsense. Not that I didn't agree that the CS/E graduates from our degree were much better (on average) than the graduates from those 3 or 4 year CS/E courses, but rather the stupid notion that it would be perfectly fine (and ideal) for a software team to have one or two good software engineers as project leaders/managers/architects, and the rest to be code monkeys... These seniors students were completely blind to the importance of having the majority of your developers be good, smart developers (even if junior ones). One or two of such seniors even went so far as to comment that programming itself was a lowly task, for trolhas only... we the Engineers might program in the first 2-3 years after entering the workplace, but we would gradually move to a architure/design role in enterprise and soon would not need program anymore... [end of quote, and you could feel in these comments how much this guy really disliked programming... ] Man, my eyes went cartoonishly wide open when I read this. How incredibly deluded this guy was... :S But the whole surprising thing is, I wasn't expecting this kind of attitude in other countries, I thought this was somewhat isolated in Portugal... a mix of personal delusion (derived from the fact that actually these guys sucked at programming, or anything else useful), combined with a still lingering non-meritocratic class arrogance in Portuguese society. Nobility may be long gone, but there are a lot of people in Portugal who like to put themselves about other people, and having a degree (especially with title-conferring degrees, which engineering degrees are btw) is a very common excuse for people trying to make themselves look superior, (even if their degree was crappy, or they sucked at it). -- Bruno Medeiros - Software Engineer
Re: blog: Overlooked Essentials for Optimizing Code (Software Engineering degrees)
In most Europe, Engineering is always a 5 years (masters) degree, oriented to big project developers who'll (supposedly) lead teams. I've heard it's different in the Anglosaxon systems. Whoa! :o Shit, I'm going to go on a big tangent here, but I'm very surprised to again hear that notion that the 5 year CS/Engineering degrees in Europe are for big project developers who'll (supposedly) lead teams.. In my university (which, btw, is widely regarded as the best technical/engineering school in Portugal), that idea was often mentioned by some of the senior students in my degree. The details of their opinions varied, but generally some of them seemed to think that our graduates would soon become project managers and/or software architects in the workforce, whereas most of the programming and grunt work would be left to the trolhas: the lowly developers who took the subprime 3 year practical courses in other universities/polytechnics. (Trolha is Portuguese slang for a bricklayer, or also any guy who does construction work... see the metaphor here?) Obviously I found this whole idea to be complete nonsense. Not that I didn't agree that the CS/E graduates from our degree were much better (on average) than the graduates from those 3 or 4 year CS/E courses, but rather the stupid notion that it would be perfectly fine (and ideal) for a software team to have one or two good software engineers as project leaders/managers/architects, and the rest to be code monkeys... These seniors students were completely blind to the importance of having the majority of your developers be good, smart developers (even if junior ones). One or two of such seniors even went so far as to comment that programming itself was a lowly task, for trolhas only... we the Engineers might program in the first 2-3 years after entering the workplace, but we would gradually move to a architure/design role in enterprise and soon would not need program anymore... [end of quote, and you could feel in these comments how much this guy really disliked programming... ] Man, my eyes went cartoonishly wide open when I read this. How incredibly deluded this guy was... :S But the whole surprising thing is, I wasn't expecting this kind of attitude in other countries, I thought this was somewhat isolated in Portugal... a mix of personal delusion (derived from the fact that actually these guys sucked at programming, or anything else useful), combined with a still lingering non-meritocratic class arrogance in Portuguese society. Nobility may be long gone, but there are a lot of people in Portugal who like to put themselves about other people, and having a degree (especially with title-conferring degrees, which engineering degrees are btw) is a very common excuse for people trying to make themselves look superior, (even if their degree was crappy, or they sucked at it). Well, I am not sure you got what I meant. What I said is not that engineers will never code or won't have to after a couple years. The idea is more that engineers will be able to have people with different skills to manage, or to work closely with, so they'll have to know many fields to understand the whole thing. And I was not talking specifically about computers, but about all kinds of engineering. Engineering is about understanding and developping projects as a whole, which doesn't exclude working also on the details. Of course, many engineers may end doing different things, which is another advantage of the generalist approach. I'm actually doing websites now!
Re: blog: Overlooked Essentials for Optimizing Code
Hello Bruno, On 31/10/2010 05:35, BCS wrote: Hello Bruno, Which degree did 'Software engineers' take then? You know, that's one thing that kinda irks me: Why is it called 'Software engineers' when I've never seen engineering taught in a CS course (not to be confused with real computer engineering courses that are a lot more like EE than CS). What are you referring to when you say called 'Software engineers' ? The people who write software, or the college degrees/programs? I didn't quite get it. I've never seen the details of a software engineering program so I can't say much on that, but my current job title is software engineer and I know *I'm* not doing engineering. The most direct example of this I know of is in The Pragmatic Programmer: Item 18 is estimate to avoid surprises and then goes on to describe how to do that. Well, if programming were taught as an engineering discipline, that would be a pointless (if not insulting) comment because what it is advocating is so fundamental to engineering that it goes without saying. What do you mean if programming were taught as an engineering discipline ? I'm saying that programming is *not* taught or practiced as an engineering discipline (Ok, maybe the DOD, DOE and NASA do). Furthermore, I'm presenting the fact that item 18 needs stating as evidence supported to support my assertion and supporting that with the assertion that any practitioner of an engineering discipline wouldn't need to be told about item 18. To be totally clear, I'm not saying that software development should be done as an engineering process, but that the standard practices (and job title) of today shouldn't claim to be engineering.
Re: blog: Overlooked Essentials for Optimizing Code
Hello Bruno, Which degree did 'Software engineers' take then? You know, that's one thing that kinda irks me: Why is it called 'Software engineers' when I've never seen engineering taught in a CS course (not to be confused with real computer engineering courses that are a lot more like EE than CS). The most direct example of this I know of is in The Pragmatic Programmer: Item 18 is estimate to avoid surprises and then goes on to describe how to do that. Well, if programming were taught as an engineering discipline, that would be a pointless (if not insulting) comment because what it is advocating is so fundamental to engineering that it goes without saying.
Re: blog: Overlooked Essentials for Optimizing Code
On 22/10/2010 15:56, Diego Cano Lagneaux wrote: Well, you think wrongly. :) If you look at the top universities worldwide, the majority of them have only one computer programming undergraduate degree. Sometimes it is called Computer Science (typical in the US), other times it is called Computer Engineering, Informatics Engineering, Software Engineering, Informatics Science or something like that (typical in Europe), but despite the different names they are essentially the same: courses designed to _teach and educate future software engineers_. I must nuance: as an European* Informatics (and Applied Maths**) engineer, I can say this degree is not 'Software engineer' but indeed 'whole computer engineer' as we studied both software and hardware, to the point of building a complete (simulated) processor. Furthermore, I can't recall they told us about profiling tools, but it was 10 years ago and I skiped a few classes, so it means nothing. Which degree did 'Software engineers' take then? -- Bruno Medeiros - Software Engineer
Re: blog: Overlooked Essentials for Optimizing Code
En Mon, 25 Oct 2010 13:22:02 +0200, Bruno Medeiros brunodomedeiros+s...@com.gmail escribió: On 22/10/2010 15:56, Diego Cano Lagneaux wrote: Well, you think wrongly. :) If you look at the top universities worldwide, the majority of them have only one computer programming undergraduate degree. Sometimes it is called Computer Science (typical in the US), other times it is called Computer Engineering, Informatics Engineering, Software Engineering, Informatics Science or something like that (typical in Europe), but despite the different names they are essentially the same: courses designed to _teach and educate future software engineers_. I must nuance: as an European* Informatics (and Applied Maths**) engineer, I can say this degree is not 'Software engineer' but indeed 'whole computer engineer' as we studied both software and hardware, to the point of building a complete (simulated) processor. Furthermore, I can't recall they told us about profiling tools, but it was 10 years ago and I skiped a few classes, so it means nothing. Which degree did 'Software engineers' take then? Well, depends of what you mean by Software engineer. They could take a 3 years 'informatics' degree, which is not an engineering degree (even if it's called 'technical engineering in Spain) but is perfect for coders, or take the full 'informatics engineering' and just specialize later (or forget everything they don't need), for a more general and advanced degree. In most Europe, Engineering is always a 5 years (masters) degree, oriented to big project developers who'll (supposedly) lead teams. I've heard it's different in the Anglosaxon systems.
Re: blog: Overlooked Essentials for Optimizing Code
On 20/10/2010 16:17, dsimcha wrote: == Quote from Bruno Medeiros (brunodomedeiros+s...@com.gmail)'s Also, the notion that an intrinsic part of algorithm design is to understand what kind of data you are going to work was also mentioned in one of the core curricula courses in my degree (although with less detail than with case 1, above). I don't mean to offend anyone, but if you CS degree (at least for the last decade or so), doesn't teach about points 1 and 2 above as part of core curricula, then it's a pretty crappy CS degree. The same is probably also true for other related degrees (*-engineering, maths), at least with regards to point 1. You have a point to some degree, but I've noticed two related themes from my experience with my Ph.D. research and with the D community. Both of these are things Walter seems to understand and exploit exceptionally well. 1. There's a big difference between it was covered and most people actually understood it. Of course the first is a necessary condition for the second, but it's not a sufficient condition. Of course any CS/software engineering program worth its salt will recommend using a profiler, but the question is, does it sink in for most students or was it mentioned in maybe one lecture on a Friday morning when half the class was hung over and the other half was still sleeping? If a student is not paying attention, didn't go to class, or didn't study a topic, that's the student's fault and there is little that the university can (or even should) try to do change that. But that's besides the point. I wasn't arguing that a lot of students or professionals understand the issue around premature optimization and profilers. I was just arguing against [it] doesn't get taught in schools. I do agree however, that a topic can be covered with varying degrees of detail and importance. As for the premature-optimization/profiling, it was well covered in my degree. I clearly remember it being mentioned in the very first Introduction to Programming course (based on Structure and Interpretation of Computer Programs, the MIT one), where the Paretto principle as applied to programs was explained (aka the 90/10 law). And the topic was again studied during the Software Engineering course, as part of the key larger topic of how best to manage/optimize the time of the programmers and team members in a real-world project. It was also mentioned (in the context of the Agile series) that even if you know for sure that the code you are writing is indeed part of the 10% bottleneck, you likely should not optimize it yet, as changing requirements may make that code not used anymore, or no longer part of the bottleneck. As for the issue of the importance of analyzing the inputs of the algorithms, well, that one was also mentioned, but definitely not covered that well. It was mentioned in the context of hashing keys, but mostly only in passing, a lot of the nuances of the topic where not discussed. It was only recently that I learned more about this, as I watched the MIT OCW lectures of the Introduction to Algorithms course, as well as reading part of the respective book. For example the issue of deterministic hashing vs. probabilistic hashing: if you have a deterministic hashing function which indeed does distribute your input keys well on the average case, that may actually not be good enough! Because if people have access to how your hashing function works, an adversary can force the worst case to happen! (random hashing is the solution to that) I guess that with the rise of the Internet, scenarios where this matters are more common. 2. It's been done before is not a good reason not to do something if you're going to up-level it. If something's been done before at a proof-of-concept level, it's often rewarding to tweak/improve it to the point where it's practical. If it's practical, it's often rewarding to try to tweak/improve it so it's usable by mere mortals and is well integrated into whatever other stuff might be related. If it's usable by mere mortals, it's often rewarding to figure out what improvements need to be made to break barriers to widespread adoption. ?? I have not idea what you mean by this... -- Bruno Medeiros - Software Engineer
Re: blog: Overlooked Essentials for Optimizing Code
On 21/10/2010 09:02, Peter Alexander wrote: On 20/10/10 2:59 PM, Bruno Medeiros wrote: I don't mean to offend anyone, but if you CS degree (at least for the last decade or so), doesn't teach about points 1 and 2 above as part of core curricula, then it's a pretty crappy CS degree. The same is probably also true for other related degrees (*-engineering, maths), at least with regards to point 1. I don't really think of CS that way. To me, CS is to practical programming as pure math is to accounting, i.e. I don't think CS should be teaching about profiling because that's what software engineering is for. They are two different worlds in my opinion. If you wanted to get a practical programming education and you took CS then I think you took the wrong degree. Well, you think wrongly. :) If you look at the top universities worldwide, the majority of them have only one computer programming undergraduate degree. Sometimes it is called Computer Science (typical in the US), other times it is called Computer Engineering, Informatics Engineering, Software Engineering, Informatics Science or something like that (typical in Europe), but despite the different names they are essentially the same: courses designed to _teach and educate future software engineers_. A good software engineer will need a lot of the basis of CS and maths. Also those courses are nonetheless perfectly fine for someone who wishes to study CS on an academical level (ie, research). It does not make sense to have a separate undergraduate degree (other than the CS degree or the Math degree), and in some cases it also does not make sense to have a separate graduate degree (MSc.). -- Bruno Medeiros - Software Engineer
Re: blog: Overlooked Essentials for Optimizing Code
Well, you think wrongly. :) If you look at the top universities worldwide, the majority of them have only one computer programming undergraduate degree. Sometimes it is called Computer Science (typical in the US), other times it is called Computer Engineering, Informatics Engineering, Software Engineering, Informatics Science or something like that (typical in Europe), but despite the different names they are essentially the same: courses designed to _teach and educate future software engineers_. I must nuance: as an European* Informatics (and Applied Maths**) engineer, I can say this degree is not 'Software engineer' but indeed 'whole computer engineer' as we studied both software and hardware, to the point of building a complete (simulated) processor. Furthermore, I can't recall they told us about profiling tools, but it was 10 years ago and I skiped a few classes, so it means nothing. * I studied in France, which has the weirdest way of educating engineers: 2 years in a 'prépa' or 'preparation school for the Engineering Schools entry exams', then 2 years of actual degree, and finally a postgraduate year *before graduating*. I say this to note that, although we were taught a lot of engineering ways, and we covered a wide range of topics, and it is oficially a 5 years degree, we did not have a lot of actual software courses time so some of it could be a bit shallow. However, my Uni was considered at the time the 2nd best of its field in France at the time, and France is renowned for its engineers in Europe. ** Don't ask, it was the name of the degree. And it had indeed a lot of math (~30%). -- Usando el novísimo cliente de correo de Opera: http://www.opera.com/mail/
Re: blog: Overlooked Essentials for Optimizing Code
On 20/10/10 2:59 PM, Bruno Medeiros wrote: I don't mean to offend anyone, but if you CS degree (at least for the last decade or so), doesn't teach about points 1 and 2 above as part of core curricula, then it's a pretty crappy CS degree. The same is probably also true for other related degrees (*-engineering, maths), at least with regards to point 1. I don't really think of CS that way. To me, CS is to practical programming as pure math is to accounting, i.e. I don't think CS should be teaching about profiling because that's what software engineering is for. They are two different worlds in my opinion. If you wanted to get a practical programming education and you took CS then I think you took the wrong degree.
Re: blog: Overlooked Essentials for Optimizing Code
Peter Alexander: I don't really think of CS that way. To me, CS is to practical programming as pure math is to accounting, i.e. I don't think CS should be teaching about profiling because that's what software engineering is for. They are two different worlds in my opinion. If you wanted to get a practical programming education and you took CS then I think you took the wrong degree. I think CS must teach about profiling too, because even them will need to run efficient code. If you are right, then 95% of the people are today going to CS (in an university where I keep myself around) are going to the wrong university. On the other hand informatics engineering is quite different and it teaches many things that are not fit, it's a very long course, very hard, so it's not the right place for most students. So if you are right then there's a need for a third intermediate degree, where most students will want to go, that teaches both lot of good CS and real-world software engineering :-) Bye, bearophile
Re: blog: Overlooked Essentials for Optimizing Code
On 10/21/2010 02:02, Peter Alexander wrote: I don't really think of CS that way. To me, CS is to practical programming as pure math is to accounting, i.e. I don't think CS should be teaching about profiling because that's what software engineering is for. They are two different worlds in my opinion. If you wanted to get a practical programming education and you took CS then I think you took the wrong degree. There are fundamental skills that you will need if you spend any amount of time programming, whether you are a CS student, a computational scientist, or an actual programmer. Profiling is one of these skills. -- Rainer Deyke - rain...@eldwood.com
Re: blog: Overlooked Essentials for Optimizing Code
On 10/09/2010 19:20, Walter Bright wrote: http://www.reddit.com/r/programming/comments/dc6ir/overlooked_essentials_for_optimizing_code/ Generally, an interesting article. However, there are a few points I would like to counter: Nope, it isn't avoiding premature optimization. It isn't replacing bubble sort with quicksort (i.e. algorithmic improvements). It's not what language used, nor is it how good the compiler is. It isn't writing i2 instead of i*4. It is: 1. Using a profiler 2. Looking at the assembly code being executed There is a bit confusion here. The first things (use algorithmic improvements, a better language or compiler, i 2 code, etc.) are not of the same nature as the other things (1 2 - Using a profiler and looking at the assembly ) The first are techniques for optimizing particular code, and the second ones are strategies for figuring out *which* code is best to try to optimize. It does not make sense to try to oppose the two, because the second one actually requires the first one to be useful. I mean, no code has ever improved in performance *strictly just* by using a profiler or looking at the assembly code being executed. :) But more importantly 1 and 2, (especially 1: using a profiler) are crucial elements of avoiding premature optimization. I mean, I learnt avoid premature optimization as being don't optimize code until you *know* that code is a bottleneck, and in something like 80% of the books/articles/college-courses that taught about premature optimization, they also explicitly mentioned that running a profiler was by far the best way to determine which code is the bottleneck, and that the alternative of guessing is bad, because it is often wrong. Though that is undeniably true, there are two caveats that don't get taught in schools. First and most importantly, choosing the best algorithm for a part of the program that has no participation to the performance profile has a negative effect on optimization because it wastes your time that could be better invested in making actual progress, and diverts attention from the parts that matter. I don't think its true that it doesn't get taught in schools, at least in CS university degrees. In my degree this was explained in detail at least 2 core curricula courses, and a few more times in other non-core (optional/specialization) courses. Also, (like I mentioned above) the majority of other learning material (articles, books) that talk about optimization do mention the importance of profiling. Second, algorithms' performance always varies with the statistics of the data they operate on. Even bubble sort, the butt of all jokes, is still the best on almost-sorted data that has only a few unordered items. So worrying about using good algorithms without measuring where they matter is a waste of time - your's and computer's. Also, the notion that an intrinsic part of algorithm design is to understand what kind of data you are going to work was also mentioned in one of the core curricula courses in my degree (although with less detail than with case 1, above). I don't mean to offend anyone, but if you CS degree (at least for the last decade or so), doesn't teach about points 1 and 2 above as part of core curricula, then it's a pretty crappy CS degree. The same is probably also true for other related degrees (*-engineering, maths), at least with regards to point 1. -- Bruno Medeiros - Software Engineer
Re: blog: Overlooked Essentials for Optimizing Code
== Quote from Bruno Medeiros (brunodomedeiros+s...@com.gmail)'s Also, the notion that an intrinsic part of algorithm design is to understand what kind of data you are going to work was also mentioned in one of the core curricula courses in my degree (although with less detail than with case 1, above). I don't mean to offend anyone, but if you CS degree (at least for the last decade or so), doesn't teach about points 1 and 2 above as part of core curricula, then it's a pretty crappy CS degree. The same is probably also true for other related degrees (*-engineering, maths), at least with regards to point 1. You have a point to some degree, but I've noticed two related themes from my experience with my Ph.D. research and with the D community. Both of these are things Walter seems to understand and exploit exceptionally well. 1. There's a big difference between it was covered and most people actually understood it. Of course the first is a necessary condition for the second, but it's not a sufficient condition. Of course any CS/software engineering program worth its salt will recommend using a profiler, but the question is, does it sink in for most students or was it mentioned in maybe one lecture on a Friday morning when half the class was hung over and the other half was still sleeping? 2. It's been done before is not a good reason not to do something if you're going to up-level it. If something's been done before at a proof-of-concept level, it's often rewarding to tweak/improve it to the point where it's practical. If it's practical, it's often rewarding to try to tweak/improve it so it's usable by mere mortals and is well integrated into whatever other stuff might be related. If it's usable by mere mortals, it's often rewarding to figure out what improvements need to be made to break barriers to widespread adoption.
Re: blog: Overlooked Essentials for Optimizing Code
Wed, 20 Oct 2010 14:59:21 +0100, Bruno Medeiros wrote: I don't mean to offend anyone, but if you [sic] CS degree (at least for the last decade or so), doesn't teach about points 1 and 2 above as part of core curricula, then it's a pretty crappy CS degree. The same is probably also true for other related degrees (*-engineering, maths), at least with regards to point 1. This reminds me of That is funny. Now and then you and Andrei talk so confidently about Go, C#, Haskell and other D competitors, without having written more than a couple of lines in those languages. Walter also talks so confidently about CS degrees, without having earned one. The experiences probably stem from his caltech times with the smelly bearded hippie unix guys who wrote bubble sorts in some deprecated assembler dialect. This is becoming a real problem. I gave an example of Scala fairly recently. I've given examples of code in other languages earlier. So has bearophile. I can't ever assume that you guys study these basics. The discussion stays at this level. It takes enormous amount of effort to teach simple concepts. How many knows now what a monad is? It was discussed again recently.
Re: blog: Overlooked Essentials for Optimizing Code
Every language has at least one niche (that it why they keep coming right?), but the pain is that there are tons of them. You are not expecting someone know all of them to the fullest right? If he tells you now that he knows all of it, next time you would say There is this other language got one awesome feature called donuts! You don't know it, you suck!. Many people here do this pretty often. He has every right to talk about languages IMO. You know he wrote compilers to hardest languages out there to implement. If he is wrong, it us up to you to prove him wrong, though not many times i have seen on this board that someone actually did it. Sorry but it is ugly to see all these Walter bashings(not pointing you). And he says/does nothing about it, it is hard not to respect his integrity. On Wed, 20 Oct 2010 18:59:40 +0300, retard r...@tard.com.invalid wrote: Wed, 20 Oct 2010 14:59:21 +0100, Bruno Medeiros wrote: I don't mean to offend anyone, but if you [sic] CS degree (at least for the last decade or so), doesn't teach about points 1 and 2 above as part of core curricula, then it's a pretty crappy CS degree. The same is probably also true for other related degrees (*-engineering, maths), at least with regards to point 1. This reminds me of That is funny. Now and then you and Andrei talk so confidently about Go, C#, Haskell and other D competitors, without having written more than a couple of lines in those languages. Walter also talks so confidently about CS degrees, without having earned one. The experiences probably stem from his caltech times with the smelly bearded hippie unix guys who wrote bubble sorts in some deprecated assembler dialect. This is becoming a real problem. I gave an example of Scala fairly recently. I've given examples of code in other languages earlier. So has bearophile. I can't ever assume that you guys study these basics. The discussion stays at this level. It takes enormous amount of effort to teach simple concepts. How many knows now what a monad is? It was discussed again recently. -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Re: blog: Overlooked Essentials for Optimizing Code
Actually if you reread his example on DMD runtime code, you'll see it happened! On Wed, 20 Oct 2010 16:59:21 +0300, Bruno Medeiros brunodomedeiros+s...@com.gmail wrote: I mean, no code has ever improved in performance *strictly just* by using a profiler or looking at the assembly code being executed. :)
Re: blog: Overlooked Essentials for Optimizing Code
Wed, 20 Oct 2010 19:25:04 +0300, so wrote: Every language has at least one niche (that it why they keep coming right?), but the pain is that there are tons of them. You are not expecting someone know all of them to the fullest right? If he tells you now that he knows all of it, next time you would say There is this other language got one awesome feature called donuts! You don't know it, you suck!. No, I don't expect that and I do believe in the law of diminishing returns. But some languages are part of the basic skillset of every modern developer. E.g. one mainstream statically typed app/systems language (C/C++/D/C#/Java/Ada/Object Pascal/Scala), one scripting language (Bash/Python/Ruby/Perl/PHP/Javascript/Lua/...), one pure language (Lisp/ Scheme/ML/Haskell/Prolog/...). Am I wrong, you only need to know how to program in C/C++/Java/D and make/microemacs/.bat scripts? He has every right to talk about languages IMO. You know he wrote compilers to hardest languages out there to implement. If he is wrong, it us up to you to prove him wrong, though not many times i have seen on this board that someone actually did it. I see your point, but 1) I didn't criticize his statements about languages in my post (Max Samukha mentioned it, I only pointed out the pattern) 2) I find it hard to believe he is qualified to criticize university degrees world wide. For instance Bruno probably comes from Europe (which is not a homogenic single country). Second, the quality of degrees and courses varies -- without active participation it's impossible to give accurate, objective statements about the educational system. In every place I've worked in the senior workers always mention how the young generations don't learn any useful stuff these days (polluting chainsaws instead of axes etc.). This is universal, it also happens outside software engineering. The rants of old men and women. Sorry but it is ugly to see all these Walter bashings(not pointing you). And he says/does nothing about it, it is hard not to respect his integrity. I'm not bashing him. It shows amazing dedication to the subject when one changes the field after graduating. This isn't even a rarity because many of the modern subfields of computer engineering/science simply didn't exist back then. It's just that I expect developers / computer scientists to improve their knowledge base constantly. There are no signs of the field not evolving anymore. Some things can be extrapolated from the evolution so far: - compilers will catch more errors and produce faster code - in popular languages the abstraction become higher and higher - more languages will appear - in 10 or 20 or 30 years most systems are multicore Now, how can you know whether language X (e.g. Haskell) will be suitable in the future environment? How do you know which languages are worth studying if you don't get the basics of programming language theory? How can we expect one to *design* relevant new languages without these skills? On Wed, 20 Oct 2010 18:59:40 +0300, retard r...@tard.com.invalid wrote: Wed, 20 Oct 2010 14:59:21 +0100, Bruno Medeiros wrote: I don't mean to offend anyone, but if you [sic] CS degree (at least for the last decade or so), doesn't teach about points 1 and 2 above as part of core curricula, then it's a pretty crappy CS degree. The same is probably also true for other related degrees (*-engineering, maths), at least with regards to point 1. This reminds me of That is funny. Now and then you and Andrei talk so confidently about Go, C#, Haskell and other D competitors, without having written more than a couple of lines in those languages. Walter also talks so confidently about CS degrees, without having earned one. The experiences probably stem from his caltech times with the smelly bearded hippie unix guys who wrote bubble sorts in some deprecated assembler dialect. This is becoming a real problem. I gave an example of Scala fairly recently. I've given examples of code in other languages earlier. So has bearophile. I can't ever assume that you guys study these basics. The discussion stays at this level. It takes enormous amount of effort to teach simple concepts. How many knows now what a monad is? It was discussed again recently.
Re: blog: Overlooked Essentials for Optimizing Code
No, I don't expect that and I do believe in the law of diminishing returns. But some languages are part of the basic skillset of every modern developer. E.g. one mainstream statically typed app/systems language (C/C++/D/C#/Java/Ada/Object Pascal/Scala), one scripting language (Bash/Python/Ruby/Perl/PHP/Javascript/Lua/...), one pure language (Lisp/ Scheme/ML/Haskell/Prolog/...). Am I wrong, you only need to know how to program in C/C++/Java/D and make/microemacs/.bat scripts? Of course, at least some degree of knowledge in these 3 areas is a big plus. 2) I find it hard to believe he is qualified to criticize university degrees world wide. For instance Bruno probably comes from Europe (which is not a homogenic single country). Second, the quality of degrees and courses varies -- without active participation it's impossible to give accurate, objective statements about the educational system. In every place I've worked in the senior workers always mention how the young generations don't learn any useful stuff these days (polluting chainsaws instead of axes etc.). This is universal, it also happens outside software engineering. The rants of old men and women. You are giving too much value to universities/schools, just 3-5 years and they take much more than they give. Graduating is not the end, it is a start. Well... this is my experience. :) Some things can be extrapolated from the evolution so far: - compilers will catch more errors and produce faster code - in popular languages the abstraction become higher and higher - more languages will appear - in 10 or 20 or 30 years most systems are multicore Now, how can you know whether language X (e.g. Haskell) will be suitable in the future environment? How do you know which languages are worth studying if you don't get the basics of programming language theory? How can we expect one to *design* relevant new languages without these skills? I got no idea what is going to happen one year later in this retard (not you :P ) world really. In this world you can hit jackpot with : - a search engine. - a web page you can post videos where you can get racist comments for anything you post. - a web page you can post links, add names to your friend list. - a web page you can post links/chat faster/cuter. And people would think these are grand ideas. A world, where using internet/coding make you nerd/antisocial but using/connecting these 4 make you social. anyways! A language should be there to solve problems i got right now, it might be obsolete the next day, who knows. *cheers -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Re: blog: Overlooked Essentials for Optimizing Code
On 10/20/10 10:59 CDT, retard wrote: Wed, 20 Oct 2010 14:59:21 +0100, Bruno Medeiros wrote: I don't mean to offend anyone, but if you [sic] CS degree (at least for the last decade or so), doesn't teach about points 1 and 2 above as part of core curricula, then it's a pretty crappy CS degree. The same is probably also true for other related degrees (*-engineering, maths), at least with regards to point 1. This reminds me of That is funny. Now and then you and Andrei talk so confidently about Go, C#, Haskell and other D competitors, without having written more than a couple of lines in those languages. Walter also talks so confidently about CS degrees, without having earned one. The experiences probably stem from his caltech times with the smelly bearded hippie unix guys who wrote bubble sorts in some deprecated assembler dialect. This is becoming a real problem. I gave an example of Scala fairly recently. I've given examples of code in other languages earlier. So has bearophile. I can't ever assume that you guys study these basics. The discussion stays at this level. It takes enormous amount of effort to teach simple concepts. How many knows now what a monad is? It was discussed again recently. I think you are making a good point, and that the best way to realize its potential is to contribute more concrete ideas and artifacts that can be integrated within D to the extent possible. It's one thing to discuss monads, it's another to demonstrate how threading a monad through a pure D function achieves something that couldn't have been achieved otherwise. Andrei
Re: blog: Overlooked Essentials for Optimizing Code
Jesse Phillips schrieb: Is there information on what the output of trace.log and trace.def mean? And I guess I can run the demaingler against this output, any tools already handle this? Documentation of the profilers output would be helpful indeed. That last table in trace.log is self-documenting and already contains the most important information: what function is executed how often, how much time does that take and how much of that time is used within that function itself (Func Time) opposed to the time taken by functions called from that function (Tree Time - Func Time) Don't know about the rest of trace.log though - maybe it's the fan in and fan out, which is essentially the call graph. From it, you can tell why and from where foo() is being called 1000 times when you only thought it should be called 3 times. (which a good profiler will tell you according to Walter on reddit[1])? Also: The output would be much more readable if it was demangled. A tool that parses trace.log and generates a nice (html?) representation of the data would be really cool :-) Cheers, - Daniel [1] http://www.reddit.com/r/programming/comments/dc6ir/overlooked_essentials_for_optimizing_code/c0z4yxu
Re: blog: Overlooked Essentials for Optimizing Code
Daniel Gibson metalcae...@gmail.com wrote in message news:i6fa0l$j7...@digitalmars.com... Jesse Phillips schrieb: Is there information on what the output of trace.log and trace.def mean? And I guess I can run the demaingler against this output, any tools already handle this? Documentation of the profilers output would be helpful indeed. That last table in trace.log is self-documenting and already contains the most important information: what function is executed how often, how much time does that take and how much of that time is used within that function itself (Func Time) opposed to the time taken by functions called from that function (Tree Time - Func Time) Don't know about the rest of trace.log though - maybe it's the fan in and fan out, which is essentially the call graph. From it, you can tell why and from where foo() is being called 1000 times when you only thought it should be called 3 times. (which a good profiler will tell you according to Walter on reddit[1])? Also: The output would be much more readable if it was demangled. A tool that parses trace.log and generates a nice (html?) representation of the data would be really cool :-) An interactively-inspectible one would be really great. (More work though, obviously.)
Re: blog: Overlooked Essentials for Optimizing Code
Nick Sabalausky schrieb: Daniel Gibson metalcae...@gmail.com wrote in message news:i6fa0l$j7...@digitalmars.com... Jesse Phillips schrieb: Is there information on what the output of trace.log and trace.def mean? And I guess I can run the demaingler against this output, any tools already handle this? Documentation of the profilers output would be helpful indeed. That last table in trace.log is self-documenting and already contains the most important information: what function is executed how often, how much time does that take and how much of that time is used within that function itself (Func Time) opposed to the time taken by functions called from that function (Tree Time - Func Time) Don't know about the rest of trace.log though - maybe it's the fan in and fan out, which is essentially the call graph. From it, you can tell why and from where foo() is being called 1000 times when you only thought it should be called 3 times. (which a good profiler will tell you according to Walter on reddit[1])? Also: The output would be much more readable if it was demangled. A tool that parses trace.log and generates a nice (html?) representation of the data would be really cool :-) An interactively-inspectible one would be really great. (More work though, obviously.) Via integration into an IDE maybe? That'd be cool - run the profiler and afterwards click on the function names in the representation to get to the functions and to the points they're called (from the fan in/out data) - maybe with annotations in/next to the source or something like that. If any IDE dev reads this: Proper integration of the profiler would be a killer feature :-) (But honestly I'd be thankful for any IDE with proper auto completion and maybe refactoring that works on Linux - the eclipse plugins don't seem to work for me, codeblocks neither..)
Re: blog: Overlooked Essentials for Optimizing Code
Sean Kelly Wrote: == Quote from Bane (branimir.milosavlje...@gmail.com)'s article DMD built in profiler don't work yet with multithreaded apps. Is there a plan to change that or.. ? Yes. It's on my to do list, but other things have had priority. Thanks for reply. Can I help with something? I don't have mush experience with that, though.
Re: blog: Overlooked Essentials for Optimizing Code
Bane Wrote: Sean Kelly Wrote: == Quote from Bane (branimir.milosavlje...@gmail.com)'s article DMD built in profiler don't work yet with multithreaded apps. Is there a plan to change that or.. ? Yes. It's on my to do list, but other things have had priority. Thanks for reply. Can I help with something? I don't have mush experience with that, though. I tried a quick adaption a while back and failed... the code uses globals directly within functions sometimes and not others, etc. It's really going to take a substantial rewrite to get things right. The basic idea is that each thread will keep its own data and merge it into a collective dataset on termination.
Re: blog: Overlooked Essentials for Optimizing Code
Sean Kelly Wrote: Bane Wrote: Sean Kelly Wrote: == Quote from Bane (branimir.milosavlje...@gmail.com)'s article DMD built in profiler don't work yet with multithreaded apps. Is there a plan to change that or.. ? Yes. It's on my to do list, but other things have had priority. Thanks for reply. Can I help with something? I don't have mush experience with that, though. I tried a quick adaption a while back and failed... the code uses globals directly within functions sometimes and not others, etc. It's really going to take a substantial rewrite to get things right. The basic idea is that each thread will keep its own data and merge it into a collective dataset on termination. I'll dig the dmd code to see whats going on, but my love for c is bit rusty... Thanx.
Re: blog: Overlooked Essentials for Optimizing Code
Bane Wrote: Sean Kelly Wrote: Bane Wrote: Sean Kelly Wrote: == Quote from Bane (branimir.milosavlje...@gmail.com)'s article DMD built in profiler don't work yet with multithreaded apps. Is there a plan to change that or.. ? Yes. It's on my to do list, but other things have had priority. Thanks for reply. Can I help with something? I don't have mush experience with that, though. I tried a quick adaption a while back and failed... the code uses globals directly within functions sometimes and not others, etc. It's really going to take a substantial rewrite to get things right. The basic idea is that each thread will keep its own data and merge it into a collective dataset on termination. I'll dig the dmd code to see whats going on, but my love for c is bit rusty... Thanx. The code is in druntime. src/rt/trace.d, I believe.
blog: Overlooked Essentials for Optimizing Code
http://www.reddit.com/r/programming/comments/dc6ir/overlooked_essentials_for_optimizing_code/
Re: blog: Overlooked Essentials for Optimizing Code
Walter Bright: It turns out that dmd's runtime library function had a crummy implementation of long division in it. In that case I have spent few hours narrowing the problem to a very small benchmark. Then I have left to you to spot and fix the precise cause of the low performance. And today I know x86 assembly a bit better :-) I know a person who has done it (looked at the JIT output) with Java using a debugger, I have done this often, many of my bug reports for LLVM compare the asm produced by LLVM with the asm produced by the Sun JavaVM: http://weblogs.java.net/blog/2008/03/30/deep-dive-assembly-code-java See for example: http://llvm.org/bugs/show_bug.cgi?id=5501 Bye, bearophile
Re: blog: Overlooked Essentials for Optimizing Code
bearophile wrote: Walter Bright: It turns out that dmd's runtime library function had a crummy implementation of long division in it. In that case I have spent few hours narrowing the problem to a very small benchmark. Then I have left to you to spot and fix the precise cause of the low performance. And today I know x86 assembly a bit better :-) Please forgive me for ragging on about this, but you had originally concluded that it was the code generator's fault. My point is that drawing such a conclusion would lead one to spend many hours fruitlessly looking in the wrong place for a solution, and that looking at the assembler would quickly point one in the right direction to getting it fixed. I wrote about this issue because I see it all the time, and by experienced programmers. I know a person who has done it (looked at the JIT output) with Java using a debugger, I have done this often, many of my bug reports for LLVM compare the asm produced by LLVM with the asm produced by the Sun JavaVM: http://weblogs.java.net/blog/2008/03/30/deep-dive-assembly-code-java See for example: http://llvm.org/bugs/show_bug.cgi?id=5501 Very nice, you should post that on reddit!
Re: blog: Overlooked Essentials for Optimizing Code
Walter Bright: Please forgive me for ragging on about this, but you had originally concluded that it was the code generator's fault. I was wrong, of course. For me a compiler was a black box, I didn't understand the difference between code generation and calling a built-in div function. Thank you for listening to me, for fixing that performance problem, and for all the answers you have given in the last years :-) Bye, bearophile
Re: blog: Overlooked Essentials for Optimizing Code
Walter Bright Wrote: http://www.reddit.com/r/programming/comments/dc6ir/overlooked_essentials_for_optimizing_code/ I don't like profilers, they slow the execution of my code by like a bagillian times. Actually this article got me to try it again and is the first time I noticed a difference. You've always promoted the built in profiler in D so I tried it and nothing changed (at least that would be what I thought), I'd never used a profiler before so I didn't know how it should work. Is there information on what the output of trace.log and trace.def mean? And I guess I can run the demaingler against this output, any tools already handle this? .def is listing functions for me, why? The log format seems to be Section number function number number number ... End/Begin Section Is this like a standard profiler output format?
Re: blog: Overlooked Essentials for Optimizing Code
bearophile wrote: Walter Bright: Please forgive me for ragging on about this, but you had originally concluded that it was the code generator's fault. I was wrong, of course. I have a lot of respect for you for saying that.
Re: blog: Overlooked Essentials for Optimizing Code
== Quote from Bane (branimir.milosavlje...@gmail.com)'s article DMD built in profiler don't work yet with multithreaded apps. Is there a plan to change that or.. ? Yes. It's on my to do list, but other things have had priority.
