Once the Surface Pro 3 is running all the antimalware programs you'd want on a PC, THEN run the comparisons again, and I think you'd find the others quite comparable.
I dont have antimalware on the Linux or Windows partitions of my SP2, I use Chrome for browsing and dont download/open suspicious files, I take the same precautions on my Nexus and on iOS which is why I havent had any malware issues so what specifically should I be concerned about?
I have a Surface Pro 2 and I get about 7 hours out of it, admittedly I'm usually running at full screen brightness and doing moderately intensive graphics stuff so depending on your use case you might get more.
How about a meaningful rating? Like comparing speed of tablets that cost about the same and have the same size screens and same amount of memory? And how about rating the number of quality apps? How about comparing features? And ask users which tablet OS they like best? There is a lot more to picking the right tablet than just speed.
Of course, but I don't see anywhere there that they have attempted to rate which tablet is "best", just which is the "fastest". If your consideration is more toward performance then obviously a "comparison of current tablets' peformance" would be interesting to you.
Because it is based on Mantle, which is not Metal.
Put up, or shut up
Sure, it's not hard to use Google but it's obviously beyond you. So Here, here and probably plenty of other places.
instead of basing all your "arguments" on the fact that you have an irrational hatred for Apple.
Sorry but it's not irrational and it's not "hatred", I know there are Apple fanboys and there are Apple users, I'm the latter because don't have an emotional attachment to the company.
So to you "Zero times faster" and "One time the original speed" are the same?
Of course they are, they're redundant but they are the same. If you think differently then I would be interested to hear your explanation. The language describes the math, so what math do you think is being described?
And "minus half times faster" the same as "half the speed"?
Ok. As I said, I don't know for sure, and I haven't the slightest clue about game development; however, if there wasn't a performance improvement to be had with Metal, why would Apple spend what must be thousands of hours doing development, documentation, testing, internal training, etc.on Metal? And "Lock-in" isn't a good-enough reason, due to the fact that, except for possibly in iOS, Apple still holds a severely-minority stake in the PC gaming market, and the fact that developers are still free to use OpenGL.
Metal, DirectX (more specifically Direct3D) and OpenGL are not about "game development" they are about using the GPU for drawing, there's nothing particularly "game development" about them at all. Low driver overhead has been a key feature for the next generation of graphics APIs, Apple obviously implemented this on their iOS devices and having it on OSX as well provides an easy transition for developers within Apple's products...but why make it Apple-only?
And in the case of DirectX and Metal, in neither case do those APIs have to target specific hardware (although in Apple's case, it would be far more likely to be able to pull-of such an advantage)
The API doesn't target hardware at all. The specification and API (Application Programming Interface) are just that, where are you getting the idea that they would target specific hardware at all? When it comes to hardware drawing the implementation is down to the manufacturer of the hardware to provide the implementation (that's what the driver is for).
instead, both APIs can still offer significant performance improvements by essentially being simply a more efficient way to get from "high-level" drawing commands to the underlying BitBlt-style primitives. IOW, both could be nothing more than a more efficient "Presentation Layer", and still achieve faster overall performance, relative to the usual "Draw" API.
It seems what you're describing is just "hardware accelerated drawing".
And yes, I realize I am leaving out the fact that both DirectX and Metal also bundle a lot of common "game logic" functions for the convenience of game developers, and that that alone is a good argument for their existence
No you're not leaving that out, Metal doesn't at all, neither does OpenGL and the comparable component of DirectX - Direct3D - doesn't either.
The open source deal implies, the developer gets paid little to nothing for his work and the users get free software.
No, it doesn't imply that at all.
Isn't that why these products become popular in the first place ($0 price tag)?
No, IE also has a $0 price tag.
The developers can't pull a bait-and-switch afterwards saying they're tired of providing free software and want to add changes to the software that make them money but are harmful to the users.
But that's not what they're doing because they still are providing free software.
But open source is supposed to be about what the users want.
Only because of the idea that the users have the ability to change the code to do what they want, but the reality is they don't want to do that.
Firefox lately seems to be more about how many more millions Mozilla can make off their users and they care little about users (since they pay $0).
What's wrong with that?
So Firefox is less of a free sort of software, rather it is has become a commercial product with revenues from ads and other commercial deals with for-profit companies.
I don't think you understand the definition of "free software", it has nothing to do with making revenue or monetary value or for-profit companies.
What good is open source if users can't/won't change 2 or 3 lines of code?
Not much, which is probably why few people care about open source - developers sure - but not users.
It cannot be an Open Standard; it is proprietary for the same reason DirectX is proprietary; it has to be allowed to pull every cycle-saving, down-and-dirty, low-down, ugly trick in the book to be AS FAST AS POSSIBLE.
I'm not quite sure you understand how this works, Microsoft does not write the DirectX driver for the hardware, they just provide the specification.
It is likely written largely in old-fashioned, hand-coded, hand-optimized Assembly, with all sorts of exception code for different GPUs, etc, etc. IOW, it is the direct antithesis of the way you would write something that you were going to publish an Open Standard on.
The specification is not the same as the implementation, you don't write "old-fashioned, hand-coded, hand-optimized Assembly, with all sorts of exception code for different GPUs" into a specification.
I do not know for sure; but if I had to guess, Metal is similar in INTENT to Microsoft's DirectX API. It would be difficult to make a generic, one size fits all Open Source API as efficient as a tightly coded, highly optimized, proprietary API.
Why do you think that? It's not as though DirectX targets any significant subset of desktop computing hardware over OpenGL, I don't think I've seen any benchmarks demonstrating any significant performance advantage of DirectX over OpenGL and certainly not related to the availability of the spec. Also why would it be less efficient if they released the spec?
Remember? Apple tried going the OSS route with OpenGL, and people complained about sluggish performance of games on OS X vs Windows; so they took a page out of the MS manual and decided to write their own "DirectX"-type API.
OpenGL isn't OSS - in fact pretty much all commercial implementations are proprietary, the spec is open if that's what you mean but I don't see how that affects performance - and the performance issue vs Windows is not down to DirectX which is why we don't see this "sluggish performance" issue in Windows vs Linux (take a look at games available on Steam), in fact the DirectX improvements for low driver overhead that Metal is doing are in DirectX 12 which isn't even commercially available yet.
Submitting Metal last year for standardization would have been a waste of everybody's time.
I'm not saying "submit it for standardization", even AMD didn't do that with Mantle. I'm not saying they shouldn't have done it created it either, just that if they do then don't make it yet another vendor-specific, closed, proprietary API.
- It only worked on A8/PowerVR. Apple didn't know if they could generalize it.
Where did the idea that "Apple didn't know if they could generalize it" come from?
There is probably little interest now for Apple to submit Metal as a standard.
I didn't say they should, just that they should be working with the standards body they are part of rather than creating their own closed, proprietary competing specification and API that nobody else can use.
Standards ratifications are really hard, especially if somebody on the committee doesn't like you.
Look up Apple's attempt to standardize Bonjour (Zeroconf) with the IETF.
Just because they had problems with the IETF doesn't mean they would have problems with Khronos, in fact the history of OpenCL proves the opposite. But again, I didn't say it should be pushed as a standard.
But you can look up the stories of how Google/Android is now spiking OpenCL support and pushing RenderScript.
It's odd that you say Google is "spiking" OpenCL by pushing their own RenderScript yet you don't see a problem with Apple "spiking" open graphics API standards by pushing their own proprietary Metal.
Where are you getting 10 years from? Even if it were to take 10 years for some reason, Apple are a member of Khronos so make the Metal spec open so everybody can use it.
So you understand "1.4x faster than the original speed" and "1.4x the original speed" to mean the same thing? Plenty of people say incorrect things, that doesn't mean it's not wrong.
I'm not sure what your point is, that list is just a list of things that have happened. I can see why Metal was originally created, just like Mantle but you are ignoring the fact that Apple are not independent of Khronos, they are a part of Khronos. So instead of creating their own proprietary closed specification and API why is it not open and could have been used as the basis for the new Khronos standard?
None of the points you made go anywhere toward answering that question.
1.4x is multiplication by juxtaposition in algebraic terms. However, you're quoting 1.4x faster and not 1.4x the speed (which is what was probably intended). And that would be 1x + 1.4x. Am I the only one seeing the language confusion for what it is?
I agree, the language has probably been used incorrectly, in fact that is exactly what I'm saying but you still have these morons claiming it has been used correctly and that "1.4x faster", "1.4x the original speed" and "40% faster" all mean the same thing.
But "0.4x faster" means 40% faster or 140% of the original speed. I think what you're struggling with is the understanding that the language describes a mathematical equation, maybe it's the shortening that is tripping you up:
It's not particularly complicated, if you were to say "it is 1.4x faster" what this means is "the new speed is 1.4 * {the original speed} faster {than the original speed}." So if your original speed is 10 the language is quite clearly describing the equation as: new speed = 1.4*10+10
Because it was unclear, even to Apple, if Metal could work outside their tightly integrated ARM/PowerVR designs.
So why continue that when they are a part of Khronos which has exactly the same goal?
This was a similar early concern about Mantle. To get high performance, "to the metal" often means certain requirements. Things like Apple's A8 or AMD having a unified/shared memory architecture on chip between the CPU and GPU is vastly different than Nvidia having separate VRAM from CPU RAM. Hardware differences like these are not easy to abstract away without performance loss.And for an API that is supposed to be "to the metal"/"direct to hardware", nobody wanted to repeat the current problems we have with OpenGL.
I'm not quite sure what you're trying to say there because it turns out this was not that big of an issue at all. Indeed we saw this early on with Mantle (if you were in the developer program) which is precisely why AMD contributed it to glNext so why is Apple now creating their own proprietary hardware-agnostic 3D graphics API for the desktop? It's just more pointless fragmentation, we have been through this vendor-specific situation before.
If you're whining about stuff not being open source was real, you'd have taken the opportunity to congratulate Apple today for making Swift open source.
So because I care about the graphics API but not Swift I'm not allowed to criticize a particular element of it without first congratulating them on the thing I don't care about? Seriously some of you people take Apple way too personally, insisting that I offer them my congratulations on open sourcing something before I'm allowed to criticize something else is ridiculous, that's demonstrating you have a serious emotional attachment. I don't see why you're so worried that I might have hurt Apple's feelings without balancing it out with a "congratulations".
But you haven't. Because you don't really care, it's just something you whine about.
You're right that I don't care about openness in general, nor did I ever say that I did. But by all means please fill me in on what the etiquette is for criticizing a particular thing that Apple does, how many pats on the back do you need me to give them before I can make a critical comment?
Slashdot Mirror
Once the Surface Pro 3 is running all the antimalware programs you'd want on a PC, THEN run the comparisons again, and I think you'd find the others quite comparable.
I dont have antimalware on the Linux or Windows partitions of my SP2, I use Chrome for browsing and dont download/open suspicious files, I take the same precautions on my Nexus and on iOS which is why I havent had any malware issues so what specifically should I be concerned about?
3 hours on battery? Have you actually used one?
I have a Surface Pro 2 and I get about 7 hours out of it, admittedly I'm usually running at full screen brightness and doing moderately intensive graphics stuff so depending on your use case you might get more.
How about a meaningful rating? Like comparing speed of tablets that cost about the same and have the same size screens and same amount of memory? And how about rating the number of quality apps? How about comparing features? And ask users which tablet OS they like best? There is a lot more to picking the right tablet than just speed.
Of course, but I don't see anywhere there that they have attempted to rate which tablet is "best", just which is the "fastest". If your consideration is more toward performance then obviously a "comparison of current tablets' peformance" would be interesting to you.
So you admit that you want Apple to use Vulkan
No, I never said I wanted Apple to use Vulkan.
because it is based on a proprietary product by somebody else, and even so it isn't ready for use.
I'm quite happy for them to use whatever they wish so long as the spec is open to promote interoperability rather than proprietary lock-in.
Because of your irrational hatred for Apple.
No, sorry but just because I don't love and praise 100% of what Apple says and does doesn't make me an "irrational hater".
How do you know Metal isn't the basis for Vulkan?
Because it is based on Mantle, which is not Metal.
Put up, or shut up
Sure, it's not hard to use Google but it's obviously beyond you. So Here, here and probably plenty of other places.
instead of basing all your "arguments" on the fact that you have an irrational hatred for Apple.
Sorry but it's not irrational and it's not "hatred", I know there are Apple fanboys and there are Apple users, I'm the latter because don't have an emotional attachment to the company.
So to you "Zero times faster" and "One time the original speed" are the same?
Of course they are, they're redundant but they are the same. If you think differently then I would be interested to hear your explanation. The language describes the math, so what math do you think is being described?
And "minus half times faster" the same as "half the speed"?
Yes, again the former is pretty redundant.
Fair enough ;) In any case I'm not opposed to Metal, just opposed to it being an Apple-only thing.
Ok. As I said, I don't know for sure, and I haven't the slightest clue about game development; however, if there wasn't a performance improvement to be had with Metal, why would Apple spend what must be thousands of hours doing development, documentation, testing, internal training, etc.on Metal? And "Lock-in" isn't a good-enough reason, due to the fact that, except for possibly in iOS, Apple still holds a severely-minority stake in the PC gaming market, and the fact that developers are still free to use OpenGL.
Metal, DirectX (more specifically Direct3D) and OpenGL are not about "game development" they are about using the GPU for drawing, there's nothing particularly "game development" about them at all. Low driver overhead has been a key feature for the next generation of graphics APIs, Apple obviously implemented this on their iOS devices and having it on OSX as well provides an easy transition for developers within Apple's products...but why make it Apple-only?
And in the case of DirectX and Metal, in neither case do those APIs have to target specific hardware (although in Apple's case, it would be far more likely to be able to pull-of such an advantage)
The API doesn't target hardware at all. The specification and API (Application Programming Interface) are just that, where are you getting the idea that they would target specific hardware at all? When it comes to hardware drawing the implementation is down to the manufacturer of the hardware to provide the implementation (that's what the driver is for).
instead, both APIs can still offer significant performance improvements by essentially being simply a more efficient way to get from "high-level" drawing commands to the underlying BitBlt-style primitives. IOW, both could be nothing more than a more efficient "Presentation Layer", and still achieve faster overall performance, relative to the usual "Draw" API.
It seems what you're describing is just "hardware accelerated drawing".
And yes, I realize I am leaving out the fact that both DirectX and Metal also bundle a lot of common "game logic" functions for the convenience of game developers, and that that alone is a good argument for their existence
No you're not leaving that out, Metal doesn't at all, neither does OpenGL and the comparable component of DirectX - Direct3D - doesn't either.
Mozilla is a not-for-profit foundation.
Right, so the money they do make gets poured back into development to create better products.
The open source deal implies, the developer gets paid little to nothing for his work and the users get free software.
No, it doesn't imply that at all.
Isn't that why these products become popular in the first place ($0 price tag)?
No, IE also has a $0 price tag.
The developers can't pull a bait-and-switch afterwards saying they're tired of providing free software and want to add changes to the software that make them money but are harmful to the users.
But that's not what they're doing because they still are providing free software.
But open source is supposed to be about what the users want.
Only because of the idea that the users have the ability to change the code to do what they want, but the reality is they don't want to do that.
Firefox lately seems to be more about how many more millions Mozilla can make off their users and they care little about users (since they pay $0).
What's wrong with that?
So Firefox is less of a free sort of software, rather it is has become a commercial product with revenues from ads and other commercial deals with for-profit companies.
I don't think you understand the definition of "free software", it has nothing to do with making revenue or monetary value or for-profit companies.
What good is open source if users can't/won't change 2 or 3 lines of code?
Not much, which is probably why few people care about open source - developers sure - but not users.
It cannot be an Open Standard; it is proprietary for the same reason DirectX is proprietary; it has to be allowed to pull every cycle-saving, down-and-dirty, low-down, ugly trick in the book to be AS FAST AS POSSIBLE.
I'm not quite sure you understand how this works, Microsoft does not write the DirectX driver for the hardware, they just provide the specification.
It is likely written largely in old-fashioned, hand-coded, hand-optimized Assembly, with all sorts of exception code for different GPUs, etc, etc. IOW, it is the direct antithesis of the way you would write something that you were going to publish an Open Standard on.
The specification is not the same as the implementation, you don't write "old-fashioned, hand-coded, hand-optimized Assembly, with all sorts of exception code for different GPUs" into a specification.
I do not know for sure; but if I had to guess, Metal is similar in INTENT to Microsoft's DirectX API. It would be difficult to make a generic, one size fits all Open Source API as efficient as a tightly coded, highly optimized, proprietary API.
Why do you think that? It's not as though DirectX targets any significant subset of desktop computing hardware over OpenGL, I don't think I've seen any benchmarks demonstrating any significant performance advantage of DirectX over OpenGL and certainly not related to the availability of the spec. Also why would it be less efficient if they released the spec?
Remember? Apple tried going the OSS route with OpenGL, and people complained about sluggish performance of games on OS X vs Windows; so they took a page out of the MS manual and decided to write their own "DirectX"-type API.
OpenGL isn't OSS - in fact pretty much all commercial implementations are proprietary, the spec is open if that's what you mean but I don't see how that affects performance - and the performance issue vs Windows is not down to DirectX which is why we don't see this "sluggish performance" issue in Windows vs Linux (take a look at games available on Steam), in fact the DirectX improvements for low driver overhead that Metal is doing are in DirectX 12 which isn't even commercially available yet.
Submitting Metal last year for standardization would have been a waste of everybody's time.
I'm not saying "submit it for standardization", even AMD didn't do that with Mantle. I'm not saying they shouldn't have done it created it either, just that if they do then don't make it yet another vendor-specific, closed, proprietary API.
- It only worked on A8/PowerVR. Apple didn't know if they could generalize it.
Where did the idea that "Apple didn't know if they could generalize it" come from?
There is probably little interest now for Apple to submit Metal as a standard.
I didn't say they should, just that they should be working with the standards body they are part of rather than creating their own closed, proprietary competing specification and API that nobody else can use.
Standards ratifications are really hard, especially if somebody on the committee doesn't like you.
Look up Apple's attempt to standardize Bonjour (Zeroconf) with the IETF.
Just because they had problems with the IETF doesn't mean they would have problems with Khronos, in fact the history of OpenCL proves the opposite. But again, I didn't say it should be pushed as a standard.
But you can look up the stories of how Google/Android is now spiking OpenCL support and pushing RenderScript.
It's odd that you say Google is "spiking" OpenCL by pushing their own RenderScript yet you don't see a problem with Apple "spiking" open graphics API standards by pushing their own proprietary Metal.
If that is what the author meant then it is wrong. The concept that "faster" includes a baseline is a pretty concrete and very simple.
It took 10 years for the HTML 5 spec to be standardized.
It took 12 years for the C standard to be updated from C99 to the next standard - C11.
Which may have relevance if HTML5 were a GPU API or if C was a GPU API but they are not.
And you've ignored the second part, which is that the Metal spec could become a standard, except that it's proprietary and closed.
That's not what I asked, I asked if you understand those two statements to mean the same thing.
Where are you getting 10 years from? Even if it were to take 10 years for some reason, Apple are a member of Khronos so make the Metal spec open so everybody can use it.
So you understand "1.4x faster than the original speed" and "1.4x the original speed" to mean the same thing? Plenty of people say incorrect things, that doesn't mean it's not wrong.
So because version 5 of HTML took so long we should abandon all open standards in favor of everyone doing their own implementations of everything?
I'm not sure what your point is, that list is just a list of things that have happened. I can see why Metal was originally created, just like Mantle but you are ignoring the fact that Apple are not independent of Khronos, they are a part of Khronos. So instead of creating their own proprietary closed specification and API why is it not open and could have been used as the basis for the new Khronos standard?
None of the points you made go anywhere toward answering that question.
1.4x is multiplication by juxtaposition in algebraic terms. However, you're quoting 1.4x faster and not 1.4x the speed (which is what was probably intended). And that would be 1x + 1.4x. Am I the only one seeing the language confusion for what it is?
I agree, the language has probably been used incorrectly, in fact that is exactly what I'm saying but you still have these morons claiming it has been used correctly and that "1.4x faster", "1.4x the original speed" and "40% faster" all mean the same thing.
0.4x means slower, yes.
But "0.4x faster" means 40% faster or 140% of the original speed. I think what you're struggling with is the understanding that the language describes a mathematical equation, maybe it's the shortening that is tripping you up:
It's not particularly complicated, if you were to say "it is 1.4x faster" what this means is "the new speed is 1.4 * {the original speed} faster {than the original speed}." So if your original speed is 10 the language is quite clearly describing the equation as:
new speed = 1.4*10+10
It's very, very simple.
Because it was unclear, even to Apple, if Metal could work outside their tightly integrated ARM/PowerVR designs.
So why continue that when they are a part of Khronos which has exactly the same goal?
This was a similar early concern about Mantle. To get high performance, "to the metal" often means certain requirements. Things like Apple's A8 or AMD having a unified/shared memory architecture on chip between the CPU and GPU is vastly different than Nvidia having separate VRAM from CPU RAM. Hardware differences like these are not easy to abstract away without performance loss.And for an API that is supposed to be "to the metal"/"direct to hardware", nobody wanted to repeat the current problems we have with OpenGL.
I'm not quite sure what you're trying to say there because it turns out this was not that big of an issue at all. Indeed we saw this early on with Mantle (if you were in the developer program) which is precisely why AMD contributed it to glNext so why is Apple now creating their own proprietary hardware-agnostic 3D graphics API for the desktop? It's just more pointless fragmentation, we have been through this vendor-specific situation before.
If you're whining about stuff not being open source was real, you'd have taken the opportunity to congratulate Apple today for making Swift open source.
So because I care about the graphics API but not Swift I'm not allowed to criticize a particular element of it without first congratulating them on the thing I don't care about? Seriously some of you people take Apple way too personally, insisting that I offer them my congratulations on open sourcing something before I'm allowed to criticize something else is ridiculous, that's demonstrating you have a serious emotional attachment. I don't see why you're so worried that I might have hurt Apple's feelings without balancing it out with a "congratulations".
But you haven't. Because you don't really care, it's just something you whine about.
You're right that I don't care about openness in general, nor did I ever say that I did. But by all means please fill me in on what the etiquette is for criticizing a particular thing that Apple does, how many pats on the back do you need me to give them before I can make a critical comment?