Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror

Comment: Re:The ultimate ugly hack? (Score 2) 264

by Cesare Ferrari (#49635821) Attached to: C Code On GitHub Has the Most "Ugly Hacks"

float->int conversion used to be expensive on x86 processors due to default rounding modes from C, and lack of suitable built in rounding functions. Looking back, my code contained this handy function. Ugly hack or elegant performance improvement? I'd suggest that the difference comes down to comments, unit tests, and whether people die if it's got bugs ;-)

#ifdef WIN32
        #ifdef ASSUME_ROUNDING // This method relies on knowing the rounding mode of the float processor // // It relies on it being set to round to nearest and offsets the value to // calculate a truncation
                inline int convert(float f)
                {
                        int i;
                        static const float half = 0.5f;
                        _asm
                        {
                                fld f // f = f
                                fsub half // f = f - 0.5
                                fistp i // i = round(f)
                        }
                        return i;
                }
        #else // Shift the bits in the double around so that the bits can be read directly as an int
                inline int convert(double d)
                {
                        const double D2I = 1.5*(double)(126)*(double)(126);

                        double temp = d - 0.499999999 + D2I;

                        return *((int*) (&temp));
                }
        #endif
#else // On Mac we just use the standard C conversion since it doesn't suffer the performance hit // as on PC
        #define convert(x) int(x)
#endif

Comment: Re:Good, Fast and Cheap... Pick Any Two (Score 5, Insightful) 101

by Cesare Ferrari (#46315481) Attached to: FFmpeg's VP9 Decoder Faster Than Google's

My understanding is that there is no room for decode artifacts in this - you either do it right, or it's not a proper decoder. This is a proper decoder, so will produce identical output to the google standard one. I believe there are test streams with md5s for the test frames, and this decoder passes the tests.

So, it's free, and it's correct, and it's fast. I think you have pre-conceived prejudices which are in this case wrong ;-)

From my perspective, faster is good for low power devices, so if this helps spread decent video codecs to more devices, that's a win.

Comment: Possible reasons (Score 1) 509

Maybe he doesn't like concurrent code because he's been bitten by nasty bugs enough times to shy away from it. Maybe he doesn't like your source control system as he has lost heaps of work in the past trusting it to a dodgy system. Maybe he has found code reviews a waste of time, or had bad experiences with pitched battles in a meeting room. Why don't you try asking him rather than speculating? 'Hey bob, it looks to me like you aren't keen on code reviews - why is that?' would be a good start.

Alternatively, he's a bit of a jerk, or bad at his job, and i'll leave that to you to figure out for yourself.

Comment: Re:Profit & Lies (Score 1) 730

by Cesare Ferrari (#39178519) Attached to: YouTube Identifies Birdsong As Copyrighted Music
Thanks for taking the time to try and spread some info about what has happened. It's amazing how unreasonable posters are being about this - you've already said the system failed, you have corrected the mistake and are trying to stop it happening again. Obviously people here have never produced software or a process with an error in it right ? ;-)

Comment: Re:Futile (Score 1) 160

by Cesare Ferrari (#39086085) Attached to: Book Review: Java Performance
Not my experience. I'm continually impressed with how fast java and C# are, and how well systems written in these languages perform in realtime apps. Sure, you get outliers, but then you get outliers from the OS, core swaps, networking stacks, etc etc, it's just one more area you have to watch and carefully consider, that's all. I'm not suggesting that code which hasn't been thought about performs well in this environment, but that it's possible to produce perfectly functional realtime systems with these languages.

Comment: I've seen how they do this at the cinema.. (Score 1) 612

by Cesare Ferrari (#38312500) Attached to: Iranian TV Shows Downed US Drone
The clever but somewhat unorthodox hacker employed by the Iranians pulls out his Apple Laptop and types furiously at a constant rate into a window with unrelated scrolling green text. A modal dialog box appears with a progress bar slowly ramping up to 100% and the text 'Sending virus to enemy drone'. He sits back looking smug with his hands behind his head. Once 100% is achieved, he again types furiously whilst explaining to the general standing behind him that he is going to send a surprise to the american scum operators. The drone sends out some sort of pulse of energy back up the channels being used to control it, and the equipment the american scum operators are using explodes in a shower of sparks and electrical discharges, frying the operators. The hacker than pushes a single button and the drone lands on a convenient long empty road. Everyone cheers. The hacker gets the girl.

Comment: Primo Levi (Score 1) 312

by Cesare Ferrari (#38263508) Attached to: Institutional Memory and Reverse Smuggling
I seem to remember Primo Levi wrote on this subject - not sure which of his books i've read, but something about a paint factory process springs to mind. Companies do loose information - it's entropy at work. It costs to keep information intact, and unfortunately there is much information and little indication of what may be important in the future.

Comment: Re:Lenses are going to be a problem (Score 1) 209

by Cesare Ferrari (#33464384) Attached to: Canon Develops 8 X 8 Inch Digital CMOS Sensor

Because CMOS sensors can't reset quickly. Why do you think any DSLR has a shutter? If they could do without they would have removed them. Although the name suggests the technology is digital, in actual fact digital sensors use good old analog techniques to capture charge based on light falling on the sensor. This is the bit which can't be reset (drained away) quickly enough when light is still falling on the sensor. The shutter really gives a black time when you can dump charge and reset things before allowing light to build up further charge.

I believe CCD sensors can be more quickly flushed of charge, but it's still not quick enough to do without a shutter. The benefits to a DSLR of not having a shutter would be to be able to sync flash at any shutter speed. This is one area where leaf shutters are good compared to focal plane shutters (as appear on DSLRs). Hasselblad made leaf and focal plane shutter cameras, and the abilty to use the leaf lenses on the focal plane shutter cameras to give more flexibilty on flash sync.

Logic doesn't apply to the real world. -- Marvin Minsky

Working...