I had never seen a black rectangle with rounded edges before the iPhone!
The whole "trade dress" concept seems a bit silly to me in the first place but ti is beyond stupid when they can claim something as simple as their rounded rectangular design as being "trade dress".
Nothing rigorous that I've found. I've seen some things like a Mac user posting on a forum asking why Cubase was hitting harder on OS-X than Windows along with screenshots of the overall load meters that it has, but little in the way of details on methodology.
While I haven't done extensive looking, I haven't come across anything and it is something I'm interested in.
Sadly, there seems to be little interest in testing. People who own PCs can't really test it, outside of building a hackintosh, and Mac users are not very interested in testing particularly since many of them have a real need to believe their money was well spend and do not wish to do something which might challenge that idea.
If someone gave me the hardware and software I'd love to try it, but I own only a PC, and the DAW I use (Sonar) is Windows only.
The only thing I can point to with some newer data is a Sonar benchmark, conducted by their lead programmer, showing improvements in Windows 8 vs Windows 7. They found basically an across the board improvement, with no code recompile http://blog.cakewalk.com/windo... . Now that says nothing of cross platform (as I noted, Sonar is Windows only anyhow) but does indicate that MS continues to improve Windows' performance with regards to intensive time critical tasks like audio.
True, though there is some precedence. OS-X does not seem to be particularly zippy in the few cross platform app benchmarks that are to be found. A good example is DAW bench's test on Cubase, Protools, and Kontakt: http://dawbench.com/win7-v-osx.... What you see is that Cubase has a much more efficient engine than ProTools (no surprise) and that on Windows either one gets a lot more polyphony than the Mac. At any given buffer size (lower buffers are harder to deal with) Windows did better.
Pretty good test too since you are dealing with tools that have long been cross platform. Kontakt has been cross platform for its entire life, Pro Tools was Mac only until version 5 (1998ish), since when it has been cross platform, and Cubase has been cross platform since back in the DOS and Atari ST days. All the software has long development histories on both platforms, yet Windows gives superior results.
None of this means OS-X is unusable or anything, but it doesn't appear to have the performance Windows does, when pushed.
Isn't cheating allowed? Write the original OS in C, then compile, and then work on the resultant assembly code, first on optimizing, and then on adding features?
Writing C code and playing with the generated assembly might be OK for a day or two's work in learning assembly on a particular architecture. However for any half serious project its probably a terrible way to get started.
Assembly programming is not about trying to out code generate a compiler. Its about thinking of implementations that are not restricted by the semantics of a particular high level language, of being able to leverage knowledge that can not be given to the compiler, of thinking in terms of the actual hardware architecture.
Or Malaysia or Thailand and so on.
Be careful when you get on the American hate high horse, you overgeneralize and you risk looking racist.
or maybe admit it is a bit more nuanced than "not a civilized country."
Well, you could optimize for current arches, too, if you wanted to squeeze all you can out of them.
Don't need to. Their performance was already good. Optimization of an old arch was only necessary to make its performance acceptable, to make it a minimum system requirement. To enlarge the potential market at the time.
To be honest support for the old arch (and WinXP) is being dropped from the next major release of the software. So the original reference C code is going back in to simplify maintenance. The old ASM is no longer needed. The segment of the market it served effectively no longer exists.
It would be fun to redo it for new archs, I enjoy such things, but its not justifiable. I will continue to occasionally compare it against the C code out of curiosity.
It manifests differently, but it is sexism all the same. Many of the "defender of women" types really do see women as weaker, inferior. These poor little flowers just can't, CAN'T stand up for themselves. They need guys to help them out so that things can be fair! So don't worry, fair lady, they'll protect you from the evil men... unless of course you disagree with them in which case they'll attack your fiercely for having "internalized misogyny" or some such. After all, you can't be strong enough to have your own opinions!
They don't believe they are sexist, but then people who are sexist/racist/etc rarely believe they are. Make no mistake though, that's what it is. While it might manifest as seemingly good intentions, it is actually a view of gender inferiority. I mean after all, if you truly believe that women are equal to men, just as capable, then you aren't going to think they need special champions. They can, and will, handle it themselves. It is only people who view them as weaker in some way that would think they can't handle themselves. It is pretty insidious.
I think people need to start calling them out on their bullshit. Sexism under the cloak of "equality" or "justice" is little better than sexism in the form of harassment.
Apparently not by compilers.
Duh. Compilers are shit at things like vectorization. They can fail at generating decent code even with intrinsics.
Thank goodness we still have assembly language.
Single serving all the things! From flashlights to kittens, all protected with base64 encoded, dual rot13 encrypted DRM goodness!
Interestingly the k-cup patent expired and many other companies began to produce single serve packs for Keurig coffee makers. This led Keurig to redesign and produce a v2.0 coffee maker and packs, with all new patent protection. The CEO just admitted that this 2.0 plan was a total failure and they lost a ton of money.
And you're assembly is probably easy to beat with even pretty crappy SSE2 code.
Apparently not by compilers.
You don't seem to understand the purpose of writing in assembly language. Its not to optimize for the current state of the art box. It is to get acceptable performance from old legacy boxes. Some assembly in the right spot(s) can make the difference between an old architecture making the cutoff in terms of acceptable performance, of being able to include that segment of the market in your minimum system requirements.
My point is that such optimizations for the sake of the old boxes doesn't necessarily do any harm to the new boxes. That worrying about future architectures is a red herring of sorts.
if the timing is that tight, it would allow using secondhand PCs instead of ladder logic controllers.
Think high performance computing too . An entire OS that takes a small fraction of the CPU Cache.
It's an object lesson in using pure assembly. By the time you get anything useful done, technology has moved on.
Not really. I have some computational code that I wrote in assembly 4 Pentium architectures ago. Every new architecture I run it against the C implementation, freshly recompiled with a current compiler. The assembly is still faster given all the hardware and compiler improvements. Now the performance improvement is getting much smaller but it is still a win.
I'm not reallyd sure that I understand that point. To me, thst would sound reasonable for educstionsl Ãr entertainment purposes, but are there any other meaningful reasons for writing an entire OS in assembler?
The entire OS would occupy about 1/3 of an Intel i7's cache. For ultra-high performance apps that might actually be useful.
Of course that includes user land apps and such so the footprint of the OS itself would probably be far smaller.
For a page so spartan, it shouldn't have needed 3 seconds to load on a 100mbit connection.
Well it is hosting its own web page and running on a Pentium MMX 200.
"Everything should be made as simple as possible, but not simpler." -- Albert Einstein
