Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Don't Build APIs

ceklog.kindel.com

Post reply on HN
Print view View original

51–58 of 58 posts

Re: Don't Build APIs

#51

Post by masklinn »

mtts wrote: post #48
jbri wrote: post #21

Earlier quoted context omitted.

If an end-user upgrades their operating system, and Adobe WhateverIUse stops working, who do they blame?

It's not as simple as that. If it's just Adobe WhateverIUse that breaks, sure, people will blame Adobe. But if it's Adobe WhateverIUse that breaks AND WordPerfect WhateverSomeoneElseUses and maybe also Borland SomethingSomeoneElseYetAgain uses word will get around that the new operating system "breaks things" and people will stay away from it. Even if noone will ever use all three of the broken apps. In this sense, m…

> If it's just Adobe WhateverIUse that breaks, sure, people will blame Adobe.

Not a chance. People will blame Microsoft, because WhateverIUse worked perfectly before. The only parameter which changed is that they updated the OS, therefore the OS is to blame.

Re: Don't Build APIs

#52

Post by exDM69 »

bwood wrote: post #34
tmurray wrote: post #4

This post is very accurate. I build APIs for a living (CUDA), and this lines up pretty well with my experience. Writing APIs is very tough, you will get a lot of things wrong, and the fixes available to you after you realize your mistake are all ugly at best. One quick example: In CUDA, you have to explicitly copy memory to and from the GPU. We have two basic kinds of memcpy functions--synchronous and asynchronous. A…

Thanks for your work on CUDA, it's really a great tool! My one hope is that Nvidia decides to make it a direct competitor to OpenCL by allowing it to target different platforms (though I recognize that it's not completely up to Nvidia and requires cooperation from others).

What would be the value in competing with OpenCL? CUDA and OpenCL ship pretty much an identical feature set with small changes in the API. The biggest difference is that OpenCL requires you to use buffers+offsets where CUDA allows "pointers" to GPU memory.

It's nice that Nvidia has CUDA so they can go ahead and expose functionality in new GPU's without having to (first) deal with OpenCL standardization. However, for the long term, it would be better if we'd stick to OpenCL so at least parts of source code can be shared between CPU's and GPU's of different vendors.

Re: Don't Build APIs

#53

Post by exDM69 »

ryanherman wrote: post #41
tmurray wrote: post #4

This post is very accurate. I build APIs for a living (CUDA), and this lines up pretty well with my experience. Writing APIs is very tough, you will get a lot of things wrong, and the fixes available to you after you realize your mistake are all ugly at best. One quick example: In CUDA, you have to explicitly copy memory to and from the GPU. We have two basic kinds of memcpy functions--synchronous and asynchronous. A…

Crazy, you work for Nvidia? I love using CUDA for VRAY rendering. It still lacks a ton of the material support but its getting there. From your development, how much more needs to be added to CUDA and Video Cards to get more accurate renderings with full support of materials? I know VRAY has figured out some amazing ways to get around this and support multisided material recently.

CUDA does not know anything about materials, it's only an API to run code on the GPU and transfer data back and forth from main memory to gpu memory. So it's all up to VRAY devs to implement material rendering with the tools they have available.

As far as I know, there will be no revolutionary changes in GPGPU programming in the immediate near future (apart from badass-er GPUs).

Re: Don't Build APIs

#54

Post by instakill »

Public APIs are forever – you get one chance to get it right. Unless nobody's heard of your API and thus nobody uses it, in which case you're safe, but also screwed.

Re: Don't Build APIs

#55

Post by bwood »

exDM69 wrote: post #52
bwood wrote: post #34

Earlier quoted context omitted.

Thanks for your work on CUDA, it's really a great tool! My one hope is that Nvidia decides to make it a direct competitor to OpenCL by allowing it to target different platforms (though I recognize that it's not completely up to Nvidia and requires cooperation from others).

What would be the value in competing with OpenCL? CUDA and OpenCL ship pretty much an identical feature set with small changes in the API. The biggest difference is that OpenCL requires you to use buffers+offsets where CUDA allows "pointers" to GPU memory. It's nice that Nvidia has CUDA so they can go ahead and expose functionality in new GPU's without having to (first) deal with OpenCL standardization. However, for…

Competition is a good thing, and CUDA isn't a direct competitor to OpenCL because it only targets Nvidia's platform. OpenCL is obviously the longterm winner because nobody in their right mind would want to lock themselves into a single vendor. I'm saying that I would appreciate it for Nvidia to challenge that, which will drive both CUDA and OpenCL to become better.

Re: Don't Build APIs

#57

Post by btilly »

jbri wrote: post #21
btilly wrote: post #19

Earlier quoted context omitted.

I agree with all of what you just said. But I think that the post is not a good demonstration of that. Microsoft failed at keeping the surface area as small as possible. When their surface area expanded to a hack to deal with Adobe's hack of replacing code behind Microsoft's back, they went into very dangerous territory.

If an end-user upgrades their operating system, and Adobe WhateverIUse stops working, who do they blame?

They will blame both initially. Pissed off people are pissed off, and distribute blame randomly. That is the short term pain. However if it broke AND Microsoft stated up front that it really was Adobe's fault, Microsoft would have taken less of the blame. Not none, but less.

The flip side if Microsoft had bitten that painful bullet up front, then I believe that going forward companies like Adobe would have learned to not try to hack the system like they had. That would have given everyone, including Microsoft, a better reputation.

But of course Microsoft did not do that. And now Microsoft has such a history of nasty bugs that, even if Microsoft is in the right, nobody is going to believe it. (Which of course locks Microsoft into its current strategy of bending over backwards to accommodate everyone else's bugs, causing more bugs...)

Re: Don't Build APIs

#58

Post by ryanherman »

exDM69 wrote: post #53
ryanherman wrote: post #41

Earlier quoted context omitted.

Crazy, you work for Nvidia? I love using CUDA for VRAY rendering. It still lacks a ton of the material support but its getting there. From your development, how much more needs to be added to CUDA and Video Cards to get more accurate renderings with full support of materials? I know VRAY has figured out some amazing ways to get around this and support multisided material recently.

CUDA does not know anything about materials, it's only an API to run code on the GPU and transfer data back and forth from main memory to gpu memory. So it's all up to VRAY devs to implement material rendering with the tools they have available. As far as I know, there will be no revolutionary changes in GPGPU programming in the immediate near future (apart from badass-er GPUs).

Someone should get query MYSQL server working on Cuda.
Post reply on HN