Absolutely everything I produce (including this post) is encrypted with 26 rounds of a sophisticated encryption algorithm known as ROT13. Sometimes, when I'm feeling particularly concerned about the value of the IP I'm producing, I'll apply 32 or even 64 rounds of this algorithm!
I am afraid, however, that by decrypting this post, you are in violation of the DMCA. See you in court suckers!
The reason they're mouse people more than tablet people is that most software sucks on a tablet -- many on the common UI elements that work well with a mouse fail completely on a tablet. You really have to design with pen based interaction in mind.
Look at Alias SketchBook for an example of a UI that works well on tablets
No, it's close to a 2x slowdown, and that's with no vectorization opportunities. The CLR is not using the SSE unit to do floating point -- it's still issuing x87 instructions. And if you're doing single precision math (like most graphics work is) this is a bad thing.
As for poorly written code, you'll have to blame the C++ compiler -- all I did was a straight fcn call -- one function had some inline asm in it, so it was unmanaged, one did not, so it was managed. And that costs roughly 2000 cycles per call.
Just for shits and giggles, I ported the perlin noise algorithm to c# (took about 10 minutes). There was still a > 2x slowdown compared to native C++. (535 cycles/result vs 1175 -- and that's averaged over millions of iterations.)
The current MS.net CLR stinks for performance when doing floating point work. If you have anything vectorizable, it stinks even worse.
Obviously it would not be sane to do this in a real application -- what I'm trying to do is assess what (if any) the performance penalty is for running FP intensive code managed by CLR. My observations seem indicate that this penalty is between 1.7 and 1.9x.
Furthermore, there seems to be a surprisingly heavy penalty for having unmanaged code call managed code. I haven't measured it the other way around, so I can't comment on it.
noise3[i++] = computePerlinNoise3D(x, y, z);// (float, float, float) and returns float.
It appeared to be marshalling on every call. The calling function was reading the cycle counter, and was therefore unmanaged (c++), and the noise function was managed. That gave a time that was 2200 cycles more per result than having both the caller and callee managed. It is not possible to test this on mono as mono does not support mixed mode assemblies.
I was experimenting -- I have several isolated test cases, all very heavy on single precision FP, with no library calls, and I wanted to see how fast it went running under the CLR. I am not making up any numbers.
I think you mean "Not much different than a naive code compiler would do". Using the x87 sin and cos instructions is a pretty slow way to get those results -- especially if you're using single precision -- you can get the correct answers well over twice as fast by doing a few terms of the taylor series. Furthermore the Intel compiler will recognize vectorizable uses of the trig functions and compute several in parallel, resulting in an even more dramatic speedup.
x87 code is so 1980's. These days anyone wanting decent fp performance on x86 is using the SSE unit.
I suggest that you do as I have and compare actual performance of real FP intenstive code.
My experience has been that the CLR jit code generator does a very simple translation from MSIL to machine code with virtually no sophisticated optimizations.
To be more precise mono does not support mixed mode assemblies. So it's not really feasible to run managed C++ code under mono. Yes, you can load a dll with unmanaged code and call it. And it is neither pretty nor fast to do so.
Secondly, I did not "pull the numbers out of my ass" I have carefully crafted benchmarks from real code used in real applications, ran these benchmarks for many thousands of iterations, made sure that the timed runs had the caches warmed up, and used the highest precision timing available, experimented with many combinations of compile options, and compared several versions of both the MS and Intel compiler, and verified that all the different versions of the benchmarks were generating the same correct answers -- I've been doing this sort of thing for a living for decades, and I'm very careful and thorough. All my testing shows that when doing floating point computations,.net managed code operates at a roughly 1.8x performance disadvantage when compared to native code performing precisely the same operations.
Yeah -- nice try -- it's not a strawman -- The call out to unmanaged code and return each take over 1000 cycles. (And such callouts don't work at all in mono.) So something that should take about 500 cycles (3D perlin noise generation) now takes ~2500. Ouch -- just a bit slower than leaving it managed. (For image rendering with procedurally generated textures, the perlin noise generator is frequently a *huge* spike in the
Sometimes you need nice fast math functions that can take a small handful of cycles.
My beef is that.net advocates often claim it's just as fast as native code, when it is demonstrably not.
My argument is that.net is not appropriate for performance sensitive computationally intensive programs. It's fine for UI driven stuff where that code never needs to run anywhere other than windows.
Oh, and speaking of strawmen, where did I talk about hand optimized vector assembly? Or Bash? WTF?
I've found that.net imposes between a 50 to 400% performance penalty for floating point computationally intensive code as compared to native code. (One extreme example being 3D Perlin noise generation -- where the code running under.net 2.x is almost 4 times slower than native code.). If you're using the Intel 9.x compiler and it finds vectorization opportunities, the performance difference can be even larger.
And.net application startup time stinks too.
Intel's C/C++ compiler rules -- It's *so* much better than all the rest for quality of code generation it's not even funny.
Oh and Mono is not terribly useful -- it does not support mixing managed and unmanaged code, for example -- so it's only really appropriate for programs that are entirely c#. Managed C++ will not work under mono in any realistic situation.
I was pointing out that saying "You can have my X when you pry it from my cold dead hands" does not seem to slow down these sort of people very much if they have a serious desire to take your X away from you.
But you forgot about cueing the guy pointing out that one of the most important factors for vehicular power sources is energy density, and that currently hydrogen along with its containment system absolutely sucks in this regard.
All anyone has to do to get excellent tiff support is to use libtiff. I don't think I've ever encountered a tiff that it couldn't read. Yes, you do have to build it and your app with a bunch of codecs - boo-farkin-hoo. Takes all of a couple of days of dev time to integrate libtiff with all the available codecs into a typical app. (I know, because I've done it.)
If MS wanted this to really take off, they would have opensourced the codec and integrated it into libtiff. Game over for every other format (assuming their claims about the uber-excellence of their codec are actually true).
If this is the same as the last time around, they've just taken tiff, duplicated a bunch of the baseline tags for no good reason (other than to make it incompatible), added their own codec (which they could have done to tiff very easily), removed a bunch of useful stuff from tiff, and called it their own image format. It's a real hack job.
It's just MS being the MS we've come to know and love so well -- making their own binary formats in the hopes of extending their monopoly.
> Summation is you want to do business with the worlds largest consumer you follow the Security rules.
Who said anything about not doing business? I can have teleconferences or video conferences and exchange email or use live-meeting or other online tools without having to be fingerprinted -- or are you proposing to close that loophole too?
As another poster pointed out, you do not have to do business with banks and organizations that treat you like a criminal -- it's your choice. And if you choose to allow this behaviour, in a small way, you are making it worse for all of us. I suggest you stop bending over (backwards or forwards as the case may be:-) to assist these intrusions on our privacy and liberty.
In short, the horse has *not* left the barn -- it's poking its nose out, and it needs to be firmly slapped back into its stall -- as opposed to having the door held open for it.
As it is now, I avoid travelling to the US -- No, I don't appear or sound middle eastern -- I just don't like the way things are headed south of the border, and I will not spend a single tourist dollar in a country that will illegally deport a fellow Canadian citizen to be tortured in Syria for a year.
At the moment, I will travel on business -- but if they want my fingerprints for a criminal database -- then I will not travel to the US at all. I will not consent to being fingerprinted for criminal database purposes just because I'm on a business trip.
(And I'm not one of the left leaning bleeding heart liberal types:-) I tend to lean right -- but this police state crap has got to stop.)
A dangerous toy. This toy is being made for the extreme priority the good looks. The little part which suffocates when the sharp part which gets hurt is swallowed is contained generously. Only the person who can take responsibility by itself is to play.
I'm not sure how they arrived at this translation from Japanese, but there it is.
Slashdot Mirror
Hang in there -- I hope you get well soon.
You only applied 15 rounds -- everyone knows that isn't secure.
I'm safe from these lawsuits.
Absolutely everything I produce (including this post) is encrypted with 26 rounds of a sophisticated encryption algorithm known as ROT13. Sometimes, when I'm feeling particularly concerned about the value of the IP I'm producing, I'll apply 32 or even 64 rounds of this algorithm!
I am afraid, however, that by decrypting this post, you are in violation of the DMCA. See you in court suckers!
Look at a wacom cintiq -- they're really nice.
The reason they're mouse people more than tablet people is that most software sucks on a tablet -- many on the common UI elements that work well with a mouse fail completely on a tablet. You really have to design with pen based interaction in mind.
Look at Alias SketchBook for an example of a UI that works well on tablets
No, it's close to a 2x slowdown, and that's with no vectorization opportunities. The CLR is not using the SSE unit to do floating point -- it's still issuing x87 instructions. And if you're doing single precision math (like most graphics work is) this is a bad thing.
.net CLR stinks for performance when doing floating point work. If you have anything vectorizable, it stinks even worse.
As for poorly written code, you'll have to blame the C++ compiler -- all I did was a straight fcn call -- one function had some inline asm in it, so it was unmanaged, one did not, so it was managed. And that costs roughly 2000 cycles per call.
Just for shits and giggles, I ported the perlin noise algorithm to c# (took about 10 minutes). There was still a > 2x slowdown compared to native C++. (535 cycles/result vs 1175 -- and that's averaged over millions of iterations.)
The current MS
Obviously it would not be sane to do this in a real application -- what I'm trying to do is assess what (if any) the performance penalty is for running FP intensive code managed by CLR. My observations seem indicate that this penalty is between 1.7 and 1.9x.
Furthermore, there seems to be a surprisingly heavy penalty for having unmanaged code call managed code. I haven't measured it the other way around, so I can't comment on it.
noise3[i++] = computePerlinNoise3D(x, y, z); // (float, float, float) and returns float.
It appeared to be marshalling on every call. The calling function was reading the cycle counter, and was therefore unmanaged (c++), and the noise function was managed. That gave a time that was 2200 cycles more per result than having both the caller and callee managed. It is not possible to test this on mono as mono does not support mixed mode assemblies.
I was experimenting -- I have several isolated test cases, all very heavy on single precision FP, with no library calls, and I wanted to see how fast it went running under the CLR. I am not making up any numbers.
I think you mean "Not much different than a naive code compiler would do". Using the x87 sin and cos instructions is a pretty slow way to get those results -- especially if you're using single precision -- you can get the correct answers well over twice as fast by doing a few terms of the taylor series. Furthermore the Intel compiler will recognize vectorizable uses of the trig functions and compute several in parallel, resulting in an even more dramatic speedup.
x87 code is so 1980's. These days anyone wanting decent fp performance on x86 is using the SSE unit.
I suggest that you do as I have and compare actual performance of real FP intenstive code.
My experience has been that the CLR jit code generator does a very simple translation from MSIL to machine code with virtually no sophisticated optimizations.
To be more precise mono does not support mixed mode assemblies. So it's not really feasible to run managed C++ code under mono. Yes, you can load a dll with unmanaged code and call it. And it is neither pretty nor fast to do so.
.net managed code operates at a roughly 1.8x performance disadvantage when compared to native code performing precisely the same operations.
Secondly, I did not "pull the numbers out of my ass" I have carefully crafted benchmarks from real code used in real applications, ran these benchmarks for many thousands of iterations, made sure that the timed runs had the caches warmed up, and used the highest precision timing available, experimented with many combinations of compile options, and compared several versions of both the MS and Intel compiler, and verified that all the different versions of the benchmarks were generating the same correct answers -- I've been doing this sort of thing for a living for decades, and I'm very careful and thorough. All my testing shows that when doing floating point computations,
Yeah -- nice try -- it's not a strawman -- The call out to unmanaged code and return each take over 1000 cycles. (And such callouts don't work at all in mono.) So something that should take about 500 cycles (3D perlin noise generation) now takes ~2500. Ouch -- just a bit slower than leaving it managed. (For image rendering with procedurally generated textures, the perlin noise generator is frequently a *huge* spike in the
.net advocates often claim it's just as fast as native code, when it is demonstrably not.
.net is not appropriate for performance sensitive computationally intensive programs. It's fine for UI driven stuff where that code never needs to run anywhere other than windows.
Sometimes you need nice fast math functions that can take a small handful of cycles.
My beef is that
My argument is that
Oh, and speaking of strawmen, where did I talk about hand optimized vector assembly? Or Bash? WTF?
I've found that .net imposes between a 50 to 400% performance penalty for floating point computationally intensive code as compared to native code. (One extreme example being 3D Perlin noise generation -- where the code running under .net 2.x is almost 4 times slower than native code.). If you're using the Intel 9.x compiler and it finds vectorization opportunities, the performance difference can be even larger.
.net application startup time stinks too.
And
Intel's C/C++ compiler rules -- It's *so* much better than all the rest for quality of code generation it's not even funny.
Oh and Mono is not terribly useful -- it does not support mixing managed and unmanaged code, for example -- so it's only really appropriate for programs that are entirely c#. Managed C++ will not work under mono in any realistic situation.
I'm not entirely sure that I don't fail to completely misunderstand you.
I was pointing out that saying "You can have my X when you pry it from my cold dead hands" does not seem to slow down these sort of people very much if they have a serious desire to take your X away from you.
You should have been modded insightful.
But you forgot about cueing the guy pointing out that one of the most important factors for vehicular power sources is energy density, and that currently hydrogen along with its containment system absolutely sucks in this regard.
That's just completely untrue.
All anyone has to do to get excellent tiff support is to use libtiff. I don't think I've ever encountered a tiff that it couldn't read. Yes, you do have to build it and your app with a bunch of codecs - boo-farkin-hoo. Takes all of a couple of days of dev time to integrate libtiff with all the available codecs into a typical app. (I know, because I've done it.)
If MS wanted this to really take off, they would have opensourced the codec and integrated it into libtiff. Game over for every other format (assuming their claims about the uber-excellence of their codec are actually true).
Doesn't do anything tiff can't
If this is the same as the last time around, they've just taken tiff, duplicated a bunch of the baseline tags for no good reason (other than to make it incompatible), added their own codec (which they could have done to tiff very easily), removed a bunch of useful stuff from tiff, and called it their own image format. It's a real hack job.
It's just MS being the MS we've come to know and love so well -- making their own binary formats in the hopes of extending their monopoly.
I've always thought that nanotech was the new black -- now they're gone and proven me right :-)
n s_Obamas_blackness_0209.html :-)
Of course, given that it's not descended from West African slaves, is it really black?
http://www.rawstory.com/news/2007/Colbert_questio
All your bees are belong to us.
:-)
(sorry
Just as portable code is only really portable if it has been ported to a different platform at least once.
Now we get to see how effective the key revocation system (that forms part of aacs) is going to be.
Should be interesting...
SELECT * FROM database_weenies WHERE cool_factor > 0;
0 rows returned
> Summation is you want to do business with the worlds largest consumer you follow the Security rules.
:-) to assist these intrusions on our privacy and liberty.
Who said anything about not doing business? I can have teleconferences or video conferences and exchange email or use live-meeting or other online tools without having to be fingerprinted -- or are you proposing to close that loophole too?
As another poster pointed out, you do not have to do business with banks and organizations that treat you like a criminal -- it's your choice. And if you choose to allow this behaviour, in a small way, you are making it worse for all of us. I suggest you stop bending over (backwards or forwards as the case may be
In short, the horse has *not* left the barn -- it's poking its nose out, and it needs to be firmly slapped back into its stall -- as opposed to having the door held open for it.
As it is now, I avoid travelling to the US -- No, I don't appear or sound middle eastern -- I just don't like the way things are headed south of the border, and I will not spend a single tourist dollar in a country that will illegally deport a fellow Canadian citizen to be tortured in Syria for a year.
:-) I tend to lean right -- but this police state crap has got to stop.)
At the moment, I will travel on business -- but if they want my fingerprints for a criminal database -- then I will not travel to the US at all. I will not consent to being fingerprinted for criminal database purposes just because I'm on a business trip.
(And I'm not one of the left leaning bleeding heart liberal types
My favorite label warns about the following;
A dangerous toy. This toy is being made for the extreme priority the good looks. The little part which suffocates when the sharp part which gets hurt is swallowed is contained generously. Only the person who can take responsibility by itself is to play.
I'm not sure how they arrived at this translation from Japanese, but there it is.
The only bad publicity is an obituary -- and only then if you're actually dead.