Blog: PITA bugs part 4
Moderator: Moderator Team
Re: Blog: PITA bugs part 4
Maybe the bump at 126 GeV, or more prosaically the deficit in the h→γγ channel at CMS (and the excess in the same channel in ATLAS) might be due to some FPGAs conspiring against data, just because of these kind of memory corruptions
Concerning the trigger rates, my numbers (for ATLAS), just to give an idea, are: data rate 40 MHz (each 25 ns, it's the bunches spacing). 23 peta-bytes of data per second generated by ATLAS. But interesting events (Higgs production for example) are rare: one event each 0.02 second.
Ah, and of course: http://www.infographicsshowcase.com/how ... fographic/
Concerning the trigger rates, my numbers (for ATLAS), just to give an idea, are: data rate 40 MHz (each 25 ns, it's the bunches spacing). 23 peta-bytes of data per second generated by ATLAS. But interesting events (Higgs production for example) are rare: one event each 0.02 second.
Ah, and of course: http://www.infographicsshowcase.com/how ... fographic/
-
- Posts: 441
- Joined: Sat Nov 15, 2008 4:13 pm
Re: Blog: PITA bugs part 4
Since you brought up the Large Hadron Collider ...
I'm going to put some links here about one of the few rap songs I like. The LHC Rap (on YouTube or Vimeo) for more info about it see here and here.
I'm going to put some links here about one of the few rap songs I like. The LHC Rap (on YouTube or Vimeo) for more info about it see here and here.
I reserve the right to ignore any portion of any post if I deem it not constructive or likely to cause the discussion to degenerate.
Re: Blog: PITA bugs part 4
so how does time machine development goes?
-
- Posts: 123
- Joined: Wed Aug 04, 2010 7:34 pm
Re: Blog: PITA bugs part 4
I definitely agree with checking return codes. With that I fixed a few bugs in our own OS (mostly its userland; it's a microkernel architecture after all ) as well during the last few months.Z98 wrote:https://www.reactos.org/node/859
Regards,
Sven
Free Pascal compiler developer
Re: Blog: PITA bugs part 4
That's pretty interesting. But since it isn't related to ReactOS, shouldn't it go in Off-Topic?
Re: Blog: PITA bugs part 4
I don't understand why people doesn't check those. Even non-programmers should know that at least malloc should always be checked. I'm not a real programmer (only a hobbyist) and I know that.PascalDragon wrote:I definitely agree with checking return codes. With that I fixed a few bugs in our own OS (mostly its userland; it's a microkernel architecture after all ) as well during the last few months.Z98 wrote:https://www.reactos.org/node/859
Regards,
Sven
On the subject, I found just yesterday some mallocs unchecked in a little physics sandbox.
Re: Blog: PITA bugs part 4
About physicists and programming: maybe debugging ROOT might show interesting things xD (for those who do not know: http://root.cern.ch/drupal/ )
-
- Posts: 123
- Joined: Wed Aug 04, 2010 7:34 pm
Re: Blog: PITA bugs part 4
I think more often than not the opinion about such calls is "they normally work so I don't need to check them" or another good one is "I'll add error checking later, that's just for testing"... And then there are of course those changes you do quickly before a release and then you might forgot to pay of that technical debt...mrugiero wrote:I don't understand why people doesn't check those. Even non-programmers should know that at least malloc should always be checked. I'm not a real programmer (only a hobbyist) and I know that.
Regards,
Sven
Free Pascal compiler developer
Re: Blog: PITA bugs part 4
One possibility is that the programmers in question were spoiled by programming for Linux. Under Linux, malloc doesn't fail until it allocates a truly absurd amount of memory, and accidentally using too much memory leads to failures far from the allocation site, so there's not much point in even checking the return value of malloc under Linux.PascalDragon wrote:I think more often than not the opinion about such calls is "they normally work so I don't need to check them" or another good one is "I'll add error checking later, that's just for testing"... And then there are of course those changes you do quickly before a release and then you might forgot to pay of that technical debt...mrugiero wrote:I don't understand why people doesn't check those. Even non-programmers should know that at least malloc should always be checked. I'm not a real programmer (only a hobbyist) and I know that.
Regards,
Sven
Re: Blog: PITA bugs part 4
I don't think that's the case of phisycists. I myself didn't know that Linux allocates lazily, and I program mostly for Linux (although I try to keep things portable). Also, the testing methodology is wrong, if Linux allocates lazily, as malloc won't fail if none of the previously allocated pages were used, which is not the common case. Most programs allocate and then use the memory, not that far off from allocation. So, in the real world, where one uses memory after allocating it, this calls will actually end up allocating the memory, most likely before you have to call malloc again. When you surpassed the limit for allocation, malloc will start returning NULL, as it will not have enough space for its control structures. And that's probably the logic kernel programmers followed when they decided not to check for memory availability before returning the valid pointer, although I disagree with such a practice. Deferring allocation to defer overhead is reasonable, deferring checking your bank account has the funds for the checks you emit, not so much.dfeuer wrote: One possibility is that the programmers in question were spoiled by programming for Linux. Under Linux, malloc doesn't fail until it allocates a truly absurd amount of memory, and accidentally using too much memory leads to failures far from the allocation site, so there's not much point in even checking the return value of malloc under Linux.
Re: Blog: PITA bugs part 4
I myself didn't know about that, and, as a physicist too, I can assure you that they don't know that linux's malloc allocates lazily (unless maybe some people that only write physics codes, and even for them, I have doubts). We want to write things that do what we want, primarily, and those basic checks very often are not done (maybe because of an habit of writing also, e.g., C++ code where the operator new() throws an exception when a memory allocation fails??). So I'm not surprised by those kind of oversights. I even have an anecdote about those kinds of things (yet it was about obscure float <--> int conversion in some lattice QCD code).mrugiero wrote:I don't think that's the case of phisycists. I myself didn't know that Linux allocates lazily, and I program mostly for Linux (although I try to keep things portable). [...]dfeuer wrote: One possibility is that the programmers in question were spoiled by programming for Linux. Under Linux, malloc doesn't fail until it allocates a truly absurd amount of memory, and accidentally using too much memory leads to failures far from the allocation site, so there's not much point in even checking the return value of malloc under Linux.
NOTE: I don't try to apply this "philosophy" in ReactOS
Re: Blog: PITA bugs part 4
That seems much more believable to be the case.hbelusca wrote:and those basic checks very often are not done (maybe because of an habit of writing also, e.g., C++ code where the operator new() throws an exception when a memory allocation fails??).
I'd like to hear about it.So I'm not surprised by those kind of oversights. I even have an anecdote about those kinds of things (yet it was about obscure float <--> int conversion in some lattice QCD code).
Who is online
Users browsing this forum: Ahrefs [Bot], Google [Bot], Majestic-12 [Bot] and 63 guests