----BEGIN CLASS---- [13:27] #startclass [13:28] Roll Call [13:28] Messi Fc [13:28] Ashwani Kumar Gupta [13:28] Krishnanand Rai [13:28] Saikat Dey [13:28] Atul Krishna [13:28] Jason Braganza [13:28] Priyanka Sharma [13:28] Mriyam Tamuli [13:28] Santosh Kumar Shaw [13:28] Anu kumari Gupta [13:28] yurii pylypchuk [13:28] Mayank gupta [13:28] Deepika Upadhyay [13:28] Abhishek Singh [13:28] aryan tripathi [13:28] harshit jaiswal [13:28] Vaibhav Lohani [13:28] Priyansh Sourav [13:28] Abhinav Shirur [13:28] Nikita Kotak [13:28] Apoorv Goel [13:28] Akash pathak [13:28] Gaurav Sitlani [13:29] kshithij Iyer [13:29] Chiranjeev Gupta [13:29] Suraj Ghimire [13:29] Shivam Singhal [13:29] Balaji [13:29] Aniket uttam [13:29] Bhavin Gandhi [13:29] Akshay Gaikwad [13:30] Vamsi Krishna [13:30] Roll call Devesh Verma [13:30] Abhishek Das [13:32] Hi kushal, can i join this summer training? [13:32] #hello [13:33] wait [13:33] So welcome siddhesh to #dgplug [13:34] He is a regular member anyway :) [13:34] Hi siddhesh! [13:34] But, he is also the upstream developer of glibc. [13:34] I am not going to tell you what is glibc, but passing the mike to siddhesh. [13:34] Soumam Banerjee [13:34] siddhesh, stage is yours :) [13:34] kushal, please give permission [13:34] Hello siddhesh [13:34] thank you kushal :) [13:34] hello everybody! [13:34] Hi siddhesh :) [13:35] Hello. :) [13:35] Hello siddhesh [13:35] Hello siddhesh: [13:35] Hello siddhesh [13:35] Hi Siddhesh [13:35] Hello siddesh [13:35] Hi [13:35] Hello siddhesh [13:35] So I am now going to spend the next hour or so boring you about my life and how I ended up being maintainer for glibc. [13:35] Hi siddhesh [13:35] Hello siddhesh [13:35] next [13:35] siddhesh, Questions queue is also clear. [13:35] prokbird: no need to ask you can join and attend the session but first read previous logs, link is https://www.dgplug.org/irclogs/ [13:36] I obviously won't write for the whole hour, I'll quickly recount how I ended up as a maintainer and then hopefully y'all will have questions [13:36] siddhesh, I always wanted to know that, from the day I met you :) [13:36] One of my major interests has been to try and grow more systems programmers in India [13:36] So I hope it inspires some poor soul to spend their nights and days hacking away at assembly and C. [13:37] Hopefully some of you may have read up on what glibc is, but if not, it is the library that provides C programming language runtime support. [13:37] Or in simpler terms, it is the library that has everything from printf and scanf to gethostbyname and strlen to sin and cos and so on. [13:38] Unless you're programming in golang (and even there you'll have exceptions) you're using glibc. [13:38] In the 2012-2015 time frame I was among the most prolific committers to the project. That has reduced a bit now since my new (now old) job. [13:39] I do more release management and reviews now than actual patches, but I do write patches now and then :) [13:39] I still work on glibc today at Linaro, but it is specificaly for the aarch64 architecture (i.e. 64-bit ARM) for an upcoming Qualcomm server chip. [13:39] I also lead a toolchain team that does code optimizations for the aarch64 architecture, especially the upcoming server chip. [13:40] that is, massage assembly code so that it runs faster on these chips [13:40] Before I go into flashback mode, tech questions are OK, just that it's not the focus of my session. [13:41] Anyway, so a lot of people I meet today assume that I am the quintessential geek, raised from an IIT or NIT, making toy compilers and programming computers with ones and zeros. [13:41] But that is far from the truth. In fact my background is that of an ultra-typical middle/lower-middle class kid with an average education and opportunity. [13:42] I am the usual IIT-fail (practically everyone in my time was, even those who chose medicine in the end!) but instead of falling back to engineering, I fell further, into a B.Sc. [13:42] Sorry, but i got disconnected, please someone pm me what i missed in the last 5 minutes :( [13:42] pr97: ok wait [13:42] Roll call:poojaencoded [13:42] But the B.Sc. was a blessing in disguise, because that's how I discovered Free Software [13:43] and the idea that there's an OS other than Windows [13:43] I was introduced to Linux by my teacher in B.Sc., Abhijit Rao (@quasiabhi) who was the stereotypical FSF geek, including the beard [13:43] Roll call Ravindra Lakal [13:43] he later went on to become one of the legendary hackers that wrote cleartrip [13:44] Anyway, I spent 3 days and nights (bunking college of course) just to install Debian woody. Trying to figure everything out by myself was quite an adventure. [13:44] "By myself" because I am a stubborn ass and I don't look up until I give up (which I rarely do) and that means I don't even ask questions during that time. [13:45] sorry,i was also disconnected,please someone pm me from starting [13:45] me too :( [13:45] That's not the best way to solve problems of course, and I am working on that. But there are aspects of the stubbornness that have helped me. [13:45] I did succeed in installing Linux and using it and over the years, eliminated Windows from my family computer. [13:46] i.e., my mom and my sister both would use Linux. [13:46] The only blocker was a dialer program for Sify broadband because my mom (or my sis) could not use the terminal to login. [13:46] So I wrote one using reverse engineered specs on the internet. It is called antidialer. [13:46] That was my first FOSS project, something I wrote myself and published [13:47] https://sourceforge.net/projects/antidialer/ [13:47] I enjoyed writing this, but I was still a reluctant programmer, learning only enough programming to solve my problems and then promptly forgetting. [13:48] in a sense, I have not changed that aspect of me either, just ask kushal how long it took me to 'accept' python as an interesting programming language :) [13:48] all it took was a use case for it in the end, but it did take long :) [13:49] So I wasn't really immersed in technology in any sense, just using it to solve my problems. [13:49] ! [13:49] How did you get over that reluctant programmer thing [13:49] I was sold on the idea of Free software and the geek cred that using Linux had [13:49] next [13:50] What was the use case that convinced you to learn python ? [13:50] fxkundan, I haven't, I still am very selfish about my use of computers. [13:50] ! [13:50] ahole[m], I wrote it to do the microbenchmark framework in python [13:50] ! [13:50] my first version was in perl and then when I wrote it in python it just seemed nicer [13:51] I was especially sold by the list comprehension and lambdas. It is still my favourite bit of the language. [13:51] next [13:51] ! [13:51] My question was already answered [13:51] next [13:51] when were the antidialer days? just trying to build up a timeframe [13:51] Sorry for the annoying question what is a mircobenchmark framework? [13:52] jasonbraganza, I think around 2006, a bit before I graduated from MCA [13:52] thank you. think i saw it on a pcquest cd :) [13:52] ahole[m], it's a framework I wrote to test performance of functions in glibc [13:53] jasonbraganza, oh wow, I never knew it was used by people :P [13:53] next [13:53] Sometimes I think of an idea for solving problems, then I think it's unrealistic and give up - How can I correct this mindset? [13:53] *my problems [13:54] ashwanig, it's the give up bit. Large problems always look unsolvable, it's their nature. [13:54] the idea is to keep trying to break it down. [13:54] and try to make incremental progress [13:54] ! [13:54] siddhesh, Thanks [13:55] ! [13:55] ashwanig, and it really is the 'giving up' bit that is key. If the problem is important enough to you, you won't give up. So find a way to make the problem important to you. [13:55] that's how antidialer worked for me. It was *my* problem. [13:55] next [13:55] Do we need to understand the whole glibc library to start contributing [13:56] santoshShaw, nope. Like I said, find something that bothers you and then break it down so that you target a specific part of glibc [13:56] glibc is so huge [13:56] santoshShaw, I won't claim to understand all of glibc, and I don't think anybody in the glibc community would either. [13:57] How did you keep yourself motivated? I mean it's tough to work on something even if you love doing it. [13:57] for glibc or any large project, it is a piece at a time. And they're well written enough that you can follow the trail [13:57] next [13:57] Ok siddhesh: I got my mentor as you [13:57] Cyber_freak, ask only when it is your turn. [13:58] really sorry kushal [13:58] Cyber_freak, it doesn't and there are often times when I am distracted and watching cat videos [13:58] won't happen again [13:58] but every so often I get a problem that bothers me enough [13:58] or a learning opportunity (or obsession) that grips me long enough [13:58] ! [13:58] next [13:58] siddhesh, If I am trying to solving a problem by then how I get to know about the function and libraries available? [13:59] asraisingh, every library has a programming reference if that's what you're looking for. [13:59] asraisingh, for glibc there are the man pages [14:00] siddhesh, ok [14:00] thanks [14:00] all the functions in section 3 are C library functions (AFAIR) and those in 2 are syscalls, but they're also interposed by glibc [14:00] next [14:00] ok then, back to my script :D [14:00] So I wasn't really even as clued into tech as y'all are [14:00] I still remember the first (of only two) LUG Mumbai meetup that I went to, where Philip Tellis talked about the cvs versioning system. [14:01] I understood *nothing*. [14:01] Philip Tellis turns up again in the story, so stay tuned :) [14:01] I graduated from my B.Sc. and stood 2nd in my college, but did very badly in one paper - Systems Software :D [14:01] for those who are not in college, systems software is where we learn compilers, linkers and loaders [14:01] stuff I work on on a daily basis today :P [14:02] "did very badly in one paper - Systems Software" okay this sounds more like me. [14:02] I didn't care though because my career path was well planned - MCA, get an IT job, become a Lead in 2 years and a Project Manager in 3-4 years and settle abroad [14:02] Sounds familiar? That's because this was probably the most common career path plan back then :) [14:02] Sure enough, I got into MCA and again found that programming was simple enough and nobody really cared about it [14:02] All that everyone cared about was 'Leadership Skills'. [14:03] I got into TCS (I can hear people who didn't read my bio gasping!) right out of campus and spent a great 2.5 years there. [14:03] That's right, my 2.5 years in TCS were quite good :) [14:03] I worked with a financial client and there was a lot of activity there, which meant I did some very involved work with C++, SQL, C, Lex, Yacc and heaven knows what else. [14:03] My exposure to Linux helped; I was at home on their HP-UX environment. [14:03] siddhesh, compilers is in my coming semester, means I have to give more time to it. [14:03] I didn't actually grok a lot of the stuff, but I understood enough to solve my problems. [14:04] I was top of heap there and it very quickly went into my head that I might be among the best programmers around. [14:04] I met my target of becoming a Lead in 2 years - I was made Module Lead of a sub-project. [14:04] Due to that and some changes in personal life, I ended up having evenings free. [14:04] I also started feeling a bit unchallenged technically. [14:04] Then came Philip Tellis again. [14:04] Philip is this quintessential geek of the 90s. [14:04] Brilliant programmer, always focused and extremely helpful. [14:05] He was one of the earliest employees at Yahoo! India, has had a couple of startups in the US and now works for Akamai. [14:05] He also co-wrote an instant messenger called Ayttm but had to stop working on it after joining Yahoo. [14:05] Conflict of interest - ayttm reversed engineered (the EULA forbids it) the yahoo messaging protocol. [14:05] ayttm: http://ayttm.sourceforge.net [14:05] In 2017 he asked on the LUG mumbai list if someone wanted to volunteer to port ayttm (a messaging client) to gtkv2. [14:05] 'How hard could it be?' I thought, and volunteered. [14:05] And then spent the next couple of weeks just trying to build ayttm using Philip's instructions! [14:06] My stubbornness eventually won and I steadily made progress and finished the port to gtk. [14:06] I continued and rewrote the IRC plugin, the MSN plugin, the yahoo plugin, redoing the UI and so on. [14:06] I spent every free moment there, nights, weekends, every minute. [14:06] I learned practically everything there was to about C programming there, but there was a bigger lesson there. [14:06] I learned that I was a terrible programmer. I knew nothing. [14:06] That was an incredible wakeup call - learning just how bad a programmer I was. [14:07] One funny incident that reinforced this was when I found one old issue about a segfault in the ayttm issue list. [14:07] (I can't find the link to it unfortunately) [14:07] Philip had asked for a backtrace and the reporter had not responded. [14:07] I realized that the reporter was me from about a year ago! [14:07] I had not responded to Philip's request because I didn't know what a backtrace was and was too ashamed to ask! [14:07] Anyway, that anecdote aside, ayttm is also how I got a call for a job in Red Hat - for a technical support engineer. [14:08] My mother had taken that call from HR and told him off saying that her son was not interested in support, only development. [14:08] (My mother was a technical recruiter too, so she obviously 'knew' the value of development jobs over support jobs!) [14:08] It took another call from a guy who would end up being my manager (Mustafa) to convince me to interview for the job. [14:08] I finaly made it into the tech support team at RH and moved to Pune for the job. [14:08] That pretty much changed my life, because while TCS work was more challenging, I was learning the breadth and depth of the OS here. [14:09] I was *learning* here while I was solving problems at TCS, not necessarily learning anything new in technology. [14:09] I basically discovered the fun in learning here [14:09] I was still not content, because I wanted to be a devel guy at RH. [14:09] It was a bit ironic because I kinda hated RH before, being a Debian freak. (trivia: my IRC nick then was debiansid) [14:09] But when I joined I saw what an open org RH was and the work culture there was very good [14:10] I wanted to be one of the devs that made an impact. The only way I could do that was by plugging away at work. [14:10] This was easy because my natural stubbornness helped. [14:10] I was a desktop support engineer, so I would troubleshoot X, gnome, KDE, etc. [14:10] But since I was among the few people in the tech support team who could read code, I would get quite a few tickets that needed code reading. [14:10] Also segfaults - those became my speciality in the end. [14:11] I could have done a high level analysis and sent the tickets to L3 engineers, which was the process defined. [14:11] But I would spend nights and weekends trying to debug problems and come up with patches. [14:11] Some would say that I was investing too much in a company that cared only about its bottom lines, but I would argue that I was investing in my career. [14:11] and luckily for me, I could find the time. [14:11] Thanks to all of the patches I wrote I found a place in L3 engineering soon. [14:12] I ended up in the Toolchain group mainly because I had done quite a bit of problem analysis in that area. [14:12] Mind you, problem analysis - I never really wrote an original patch. [14:12] Or rather, I failed to write one every single time I tried :) [14:12] One good thing about being in tech support and looking at all those core dumps was that I became very good at reading code. [14:13] Even today, it is the one skill I cherish. [14:13] The other skill was a deep understanding of how programs run on a machine - I learned that in tech support too [14:13] imagine trying to figure out what is happening on someone else's computer based on just a core dump and some logs! [14:13] In fact, it almost became an obsession, understanding how any program executed on the machine. [14:14] This obsession was far harder than the earlier ones - it took over 6 months of constant rejections before my first patch to glibc finally landed upstream. [14:14] Rejections were fun too - Andreas Schwab was the glibc maintainer in RH at that time and he would respond with one liners. [14:14] "You've got it the other way around", he would say. [14:14] I would then have to sit for a couple of days to try and figure out what he meant :P [14:14] Tremendous learning, but I almost gave up, given that I was making faster progress in other areas, like qpid and base os. [14:15] I was one of two people in RH who understood the internals of ksh, so I could have easily made the base os engineering team. [14:15] But I was obsessed with toolchains and I knew at that time gcc was beyond me [14:15] so was glibc, but it seemed closer than gcc :) [14:15] The first glibc patch was a huge confidence booster though, and it encouraged me to continue trying harder. [14:16] In the meantime, another interesting (and lucky for me) turn of events happened - Ulrich Drepper, then maintainer of glibc, left RH and ended his contributions to glibc. [14:16] For those who don't know, Uli was the major contributor to glibc for decades and his attitude repelled a lot of contributors, almost killing the community. [14:17] After his exit, a community started forming around it with the original author of glibc (Roland McGrath), Carlos O'Donell, Joseph Myers and a few others rebooting the project. [14:17] This also left a gap in the RH toolchain team and they were looking for a glibc engineer to fill the gap. [14:17] Jeff Law (those who don't know, he is the demi-god of the gcc community) was holding fort with glibc while they looked for a replacement. [14:18] I had become quite hands-on with the code base and was helping Jeff in whatever limited capacity I could from L3. [14:18] However when I saw the opening, I dropped him an email and asked him if I qualified. [14:18] He said "why not!" and I applied, thinking that the worst that could happen was that I would get rejected. [14:18] Nisha (my wife) was instrumental in that thought, including the one where I made the move to RH. [14:18] I studied compilers furiously for the interview and ended up getting that job. [14:19] I also realized during the interview that I actually *just knew* a lot of things from having worked on them and solving problems [14:19] the reading I did wasn't very helpful, just aided my knowledge [14:19] Anyway, because of my cheap Indian salary, they could afford to hire another glibc engineer - Carlos O'Donell. [14:19] That started the best 2.5 years of my career. [14:20] Carlos and I became a sort of dream team (and great friends now, even after leaving RH) where we helped rebuild the glibc community. [14:20] Actually Carlos did most of the community building work with Joseph Myers and Roland, but hey, I think I can sneak in some credit ;) [14:20] The entire toolchain team at RH was just incredible, each with their own specialty. That is where I learned a lot, just listening to all the conversations. [14:20] From concurrency discussions with Torvald Riegel to TLS stuff with Alex Oliva [14:21] In fact, back in 2013 we were at a conference in Mountain View and Torvald and Alex argued about something (I can't remember what) the whole week! [14:21] and I remember that being a very enlightening week for me because I learned a lot from their arguments. [14:22] Throughout the 2.5 years at RH I realized that one thing was constant: [14:22] every time I learned something new, there was something else waiting to be discovered [14:22] so the more I knew, the less I knew. [14:22] The more I learn about these increasingly complicated machines, the more I realize how much I don't know. [14:23] I guess the takeaway from this is that it's easy to look at me or any other maintainer and think that we can do no wrong. [14:23] But we do, all the time. [14:23] The difference is that we fix our mistakes and learn from them. [14:23] And of course the fact that we have just managed to fail more than others :) [14:24] So right now my struggle is with gcc, the unknown frontier [14:24] ! [14:24] I'm continuously failing there, but only those who know I'm working on it can see that unfortunately [14:25] anyway, that was my story, so I'm open for questions, tech, non-tech, all types of questions are OK! [14:25] next [14:25] Now you have shifted to gcc from glibc? [14:25] ! [14:26] not shifted really, just added an interest. There are optimizations I can hand-write in glibc, but then there are optimizations that gcc would do for me. I am trying to explore how I can make gcc do that. [14:26] ! [14:26] and miserably failing right now, but some day I'll succeed :P [14:27] next [14:28] siddhesh: Failing is not really a factor. Even I start looking for projects where I can contribute in terms of code and eventually end up doing nothing at all. [14:28] ! [14:28] What advice would you give to someone starting out pretty late , final year student :-P with an average programming skills but with the whole idea of open source , thanks to those meetup groups. [14:28] siddhesh: I guess you are in a better position. [14:28] ! [14:28] ahole[m], I think that has to do with the 'scratch your itch' bit. It's all good trying to find a project to contribute to, but you won't end up doing much if you don't have skin in the game. [14:29] antidialer was an itch for me that I scratched. [14:29] ayttm was a work item that philip tossed and I grabbed. [14:29] and then once I grabbed it, I had to work on it - that's where obsession took over. [14:30] we toss these kinds of problems in all the time [14:30] like the pthread docs problem I keep mentioning to everyone who then promptly starts avoiding me :) [14:30] they key is to grab these opportunities because without them you'll be stuck waiting for that itch to scratch. [14:30] next [14:31] have you created/added any new library in glibc? [14:31] What about pthread docs? [14:32] no new libraries (because they're an ABI event that we would usually keep to a minimum). but I have added a couple of new features - microbenchmarks to measure function performance and lately, tunables to tweak settings in glibc. [14:32] ! [14:32] to mention a couple - I've worked on a bunch of other subsystems over time from math (multiple precision math performance) to malloc and nscd. [14:33] siddhesh: what is nscd? [14:33] the pthread docs are mostly non-existent. There's a glibc manual online that should have a description of all the pthread functions but it doesn't [14:33] We need volunteers to write documentation for it based on their reading of the glibc pthread implementation. [14:34] nscd is name server caching daemon. google will help you understand better what it is :) [14:34] next [14:34] "Mind you, problem analysis - I never really wrote an original patch." What did this mean? [14:34] oh, it meant that I had looked at tickets, found out what was wrong but did not know how to fix it. [14:35] So what did you do then? [14:35] To help with the ticket. [14:35] ! [14:35] I had accomplished the bit about udnerstanding the problem, but with a complex code base such as glibc, it is often hard to come up with a fix given the various tradeoffs one may have to make. [14:35] I wrote up a detailed description of what I found and how I found it. And then left it to engineering to decide what to do. [14:36] https://sourceware.org/bugzilla/show_bug.cgi?id=1190 [14:36] here's an example of how even a one line change in glibc could have huge implications. [14:36] It was one of the earliest fixes I had posted and had to give up because the problem was way beyond my scope of knowledge then. [14:37] next [14:37] What advice would you give to a even late starter a 38 year old who’s just started learning programming basics and wants to use software programming as his next career change? :P [14:37] heh, don't lose hope, you're not *that* old :) [14:37] at 35 I am among the younger gcc/glibc programmers [14:37] :) [14:38] the journey you described - 10-12 years? [14:38] age is really just a number when it comes to programming. If anything, you're much better placed to understand subtleties of programming complex systems [14:38] I started my career in 2006, but I started hacking on glibc in 2011 or so [14:38] so about 6-7 years [14:39] 6-7 years for toolchains that is [14:39] next [14:39] thank you :) [14:39] Same question :-) as jasonbraganza but I am a final year student and learning to write code efficiently and grasping programming fundamentals. [14:39] ! [14:39] so I guess you already answered it :-) [14:40] I am of a slightly different belief there; I'd say write code to solve your problems first and then look at how you can improve it to make it efficient, beautiful, etc. [14:40] over time, the beauty and efficiency will come in naturally, but if you make that a focus too early you'll lose sight of the goal. [14:40] ! [14:41] programming, hacking, etc. is an interest, not a goal. Goals are what you could use programming to achieve. [14:41] next [14:41] thank you : -) [14:41] Can you share some tips on reading code or some difficulties you faced while learning to read code? [14:42] Oh the biggest difficulty usually is trying to figure out where to start [14:42] ! [14:42] however it's a bit easier with open source because there's usually a pattern in how code is configured and built. [14:42] ! [14:42] as for trying to figure out where to start, the problem you're trying to solve should tell you that. [14:43] Look for the offending function/file and then start backtracking from there to main() [14:43] or whatever the equivalent of entry point in your programming language [14:43] it's a slow and often frustrating grind but eventually in some years you'll find yourself understanding patterns of almost completely alien code before you've read a couple of files. [14:44] it'll take years though :) [14:44] should I use debugger while reading code? [14:44] next [14:44] what advice would you give to a final year student who little bit about programming and haven't contribute anything for open source and don't know more about it [14:44] ashwanig, oh yes, extensively, if that's how it works for you [14:44] siddhesh, okay, thanks :) [14:45] but want to learn python and want to contribute [14:45] poojaencoded, hang out on these channels and mailing lists, go to meetups and workshops, look out for maintainers looking for volunteers to work on their project. [14:45] ! [14:45] ! [14:46] if you have a maintainer asking for help, half of your battle is won because (s)he will have an interest in making sure you succeed. [14:46] next [14:46] "It was one of the earliest fixes I had posted and had to give up because the problem was way beyond my scope of knowledge then." [14:46] Did you give up on that issue? When do you know when to give up? [14:46] I gave up because I did not understand even a single line of the discussion that happened on the mailing list in response to my patch :) [14:47] I had other tickets to get to because of which I had to put it on the backburner [14:47] and then when I finally got to the point of understanding what was required to fix it, I realized that it is not worth the effort. [14:48] next [14:48] Thanks for answering questions that may have sounded silly. [14:48] siddhesh, There are lots of resources to learn anything and its overwhelming for newbies. What is your single most valuable piece of advice on learning something new like a pattern you followed to master something?(Not just related to Technology) [14:48] ! [14:49] ! [14:49] im_mohsin, With respect to technology, solving bugs. The analogue in life in general is finding something that bothers you enough that you want to invest yourself in fixing it. [14:49] If you're not the kind that can read the OS Tanenbaum book from end to end, then your approach should be to pick problems to solve. [14:50] that automatically reduces the surface of the technology (or problem statement) you have to cover [14:50] next [14:50] What would you suggest ,to learn things on the go with the problem or to first get some understanding of related concepts a bit ,does it effect hacking and the productivity as you tried both in two phases of your life ? [14:51] siddhesh, thanks :) [14:51] deepika, the former helps in most cases, but there are times when you need to keep the computer aside and do some serious reading. [14:51] In fact I have a story about that :) [14:52] back in 2012-13, I did my first big project, which was to try and speed up the slow path of all of the math functions. [14:52] However, I had no clue how those functions are written and if you look at their implementation (I've added some comments in some functions now but...) they're ugly and arcane [14:52] ! [14:52] because they were written by mathematicians in IBM [14:53] and they were written with the IBM powerpc processors [14:53] so I had to get an ACM subscription and hunt for a paper by Schmuel and Gal upon which the pow function implementation was based [14:53] and then read up on how math functions are written in general [14:54] (i.e. argument range reduction, table lookup, etc.) [14:54] that was a very frustrating 1-2 months of my life because I was used to problem solving, not just reading like that [14:54] but at the same time I was doing math again, which helped tide through it. [14:55] Similar situation last month, when I have had to read about some CPU hardware prefetcher before I could even touch any code [14:55] throughout that 1-2 months I felt like I was going to be kicked out of my job because I had not written any code [14:56] but the end result was good - I improved pow 8 times and some other functions by similar factors [14:56] hoo boy! [14:56] it wasn't enough though because those paths were about 1000x slower :P [14:57] so yeah, both approaches are valid, you have to decide which one to take and often you'll take to wrong path and then return to take the correct one. [14:57] next [14:57] How would you compare system level programming with application level programming ? [14:57] siddhesh: :) [14:57]