Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Telgin]

Yeah, graphics shaders are restricted to writing out vertices, pixels and I think polygon primitives in newer geometry shaders, and as far as I know they can't do much past that.  CUDA and OpenCL definitely can though, using the same hardware.  I guess it's just a different use case since it doesn't make a whole lot of sense to use graphics shaders as generic computation like CUDA and OpenCL.

[alway]

Yeah, graphics shaders are restricted to writing out vertices, pixels and I think polygon primitives in newer geometry shaders, and as far as I know they can't do much past that.  CUDA and OpenCL definitely can though, using the same hardware.  I guess it's just a different use case since it doesn't make a whole lot of sense to use graphics shaders as generic computation like CUDA and OpenCL.

You can do pretty much everything in shaders you can in GPGPU languages. It just requires ass-backwards contortions of the structures and such therein. Data is data is data, whether it's explicitly stored as an array or stored as 'pixels.' The biggest current trend in shader language implementation is a merging with compute languages. Fixed functionality supported by subsystems in hardware replaced with multipurpose ALU with a simple software version of the instructions. DirectX 12, Mantle, Metal; all of those are explicitly about allowing you to do things in a way more similar to compute languages. But most of that is available already if you're content with jumping through horrendous hoops in code to make it happen (which is just a remnant of old-style fixed functionality in the APIs, rather than a reflection of actual GPU hardware).

[Telgin]

Hmm, that's true enough.  I suppose there's nothing stopping you from rendering to a buffer and interpreting that buffer data in whatever way you choose.

It's kind of interesting to see how the shaders languages will evolve then.  I feel so outdated with it now.  The last time I seriously tried any game development was right when vertex and fragment programs using assembly language was the cutting edge.  Back before they even had branching support.

[Telgin]

Maybe I should stop using this topic as a convenient place to rant about programming stuff?   

Anyway, I was fooling around with C++ some again earlier this week trying to get a simplistic websocket server running, with the intention of writing a simple browser based game using the C++ application as the backend.

I remember way, way back when I was first learning to program how I used to wonder why people raved so much about scripting languages compared to compiled languages.  I stopped wondering that a long time ago, but this sure gave me a strong reminder of that lesson.

It wasn't too long after I started working on it that I remembered why I don't code in C++ much anymore.  Getting a websocket server running is not simple.  It requires a lot of things that aren't directly part of C++ or its standard library.  There's obvious stuff like the network layer, but less obvious stuff like needing a SHA-1 hash generator, a base64 encoder and decoder, and a dozen other things I'm forgetting.  So, naturally, rather than waste time and reinvent the wheel I searched for a library to do it for me.  I found a couple, and that was when I was reminded of two things:

1. I generally hate working with other people's libraries
2. Coding in C++ is too much work these days

These combine to a third point: I really hate working with other people's C++ libraries.  Quadruply so if I'm working on Windows, as I was.

Both of the libraries I found were originally written with a Linux environment in mind.  Whatever, I expected as much, since apparently only the biggest open source projects care about Windows ports.  I didn't have a Git client on the computer, so I downloaded the ZIP file of one and extracted it while trying to figure out how to get it to compile in Visual Studio 2013.  Oh, great, it needs Boost.  I haven't had good experiences with Boost in the past, even on Linux, so I was scared of that.

155 MB later, I had Boost downloaded.  It took five full minutes to extract and move the many, many thousands of source files, but setting it up in VS afterward was easy enough.  I tried to compile again, and... nope, I have to compile the Boost thread library for this websocket library.

Okay, fine.  How do I do that?  After looking it up, naturally it involved some specialized build system that had to be run from the command line, since using a VS project was apparently just too crazy.  Oh, and of course, lots of the libraries fail to compile because they haven't been updated for VS 2013 yet.  These are known issues from over a year ago it seems, but Boost 1.56 isn't out yet so I'm stuck with this.

Unbelievably, the thread library was one of the few to compile, so I crossed my fingers, dug through the directories, then Googled where the heck Boost's build system dumps the libraries, and was finally able to compile my application and get it to run (after fixing some more VS 2013 related errors in the websocket library).

In the end, I realized something a little scary about the entire process: I genuinely didn't know if I should be impressed or mad that it took me 4 hours to get a purportedly cross platform and Windows supported library to compile and run.

If this was an isolated incident it wouldn't be so bad, but it was the exact same nonsense when I tried to get V8 integrated into a different application a year or so back.  It took me days to get it to compile on Windows, because it used a specialized (different!) makefile / build system that was again not ported to the current version of VS.  Which was to speak nothing of the difficulty of actually using it once it compiled, since the documentation was all but nonexistent or outdated.

This is the sort of thing that makes my reflexes jump to reinventing the wheel every time I have a problem rather than relying on someone else's solution.  If I have to use their code, I'll have to fight it forever to get it to work, then I'll have no idea what to do if it doesn't work, and even if it does work it's probably not exactly the wheel I needed.  At least if I do reinvent the wheel, it's the wheel I need and one I understand.

[Gatleos]

This is the sort of thing that makes my reflexes jump to reinventing the wheel every time I have a problem rather than relying on someone else's solution.  If I have to use their code, I'll have to fight it forever to get it to work, then I'll have no idea what to do if it doesn't work, and even if it does work it's probably not exactly the wheel I needed.  At least if I do reinvent the wheel, it's the wheel I need and one I understand.

There are days of my life I will never get back. Days. All wasted on libraries.

The only reasons I keep coming back to C++ are speed and familiarity.

[Lightningfalcon]

This talk of C++, along with a bunch of stuff I am seeing online right now, is all making me reconsider learning C++.   Is it really worth learning it?  Exactly how much speed and efficiency can I gain from programming in C++ versus Java or some other language?

[da_nang]

Versus Java, you can probably gain a decent amount (Java is not as bad as it used to be performance-wise, or so I've heard). But you could also consider looking into C# aka the child of C++ and Java with all the bad stuff supposedly genetically removed.

[Mego]

Telgin: Cygwin is a godsend for working with "cross-platform" C/C++ code.

[Maklak]

@Telgin:
Hehe. A few years back, I had an urge to finally learn a GUI toolkit to actually be able to write progams with buttons, labels and all that cool stuff. My language of choice was C/C++. I spent a few days deciding which GUI library to learn (QT 4, WxWidgets, SDL 1.2, Allegro, GTK, ...) and got so confused that I chose FLTK in the end (QT is the correct choice).

Now to get it to run I already had MinGW installed, so I tried ./configure and make and... nope, it needed zlib. Then some other libraries. Then an install script for one of those libaries needed a util that injects include and library directories into commands (pkgconfig, I think). All in all it took me about 3 days to resolve all the issues, get FLTK to compile and most of the example programs to run without crashing and I sort of lost motivation afterwards. The list of GTK dependencies was even more scary. Ugh. At least this experience helped me resolve some library dependencies when compiling a project at my first job.

A while later I tried to get Perl to run PerlTK GUI on Windows and... it had a dependency on X-Server, even  though it was supposed to be cross-platform. I gave up. Fsck yourself, Perl.

At my current job I'm working on a C# Windows service billing module that reads stuff from 2 databeses (plus 1 table each from 2 other databases), computes some payments if there are unprocessed tasks in one of the tables, then writes the results to a database. It is currently sitting at around 5k lines of code (according to Visual Studio metrics) and I keep refactoring it and adding stuff to the point that I no longer remember how it all works.
Anyway, my boss tried to install the thing at our client through a remote desktop and we sat for hours and kept bumping into issues like "OK, I need these 4 connection strings", "I need these 30 views in database", "Huh, this table is named differently. And it has one column that's called differently. Whatever, I'll just change our local database to match theirs.", "OK, to start a Windows service you need to run $ installutil <file> from developer command prompt as administrator", "Look, I need a hundred rows of the price tree from our testing database, otherwise it will just throw an exception". Now, these are just the issues with my module. Installation instructions for all of it is approaching a point where it is hard to keep track of all these small issues. Oh and the project is delayed, so 2 weeks ago we were assigned additional programmers who all write their own modules and make ass-umptions (that was a pun) about the rest. Oh joy. I guess there isn't much point in asking for a pay rise (that was a joke).

[Telgin]

This talk of C++, along with a bunch of stuff I am seeing online right now, is all making me reconsider learning C++.   Is it really worth learning it?  Exactly how much speed and efficiency can I gain from programming in C++ versus Java or some other language?

To be completely honest, the performance isn't all that different these days.  It's there, no doubt, but it's going to be negligible unless you're doing something that has to have the absolute best performance possible.  Extremely involved scientific simulations or cutting edge games, for example.  For almost anything else you're going to see such a small difference that you'd probably not want to compared to the amount of time it takes to code in C++ versus something like Java or C#.  These days there are increasingly few reasons to really use C++, with the big one being what was mentioned earlier: familiarity.  There's a ton of C++ code and libraries, especially stuff done in house at various programming studios, and people are used to it.

Of course, the story is different for purely interpreted languages, which can be amazingly slow compared to C++...

Having said that, is it worth learning C++?  It's probably worth at least learning how it works.  Or if you know C already, probably not.  Learning how some things are done under the hood, like manual memory management and dealing without lots of built in standard library stuff, can help broaden the way you think.  I'd say that knowing how pointers work has probably made my life a little easier a time or two when dealing with object references in languages like PHP and JavaScript.  Not a lot, but a little.  At the very least I do like knowing how it works.

Telgin: Cygwin is a godsend for working with "cross-platform" C/C++ code.

I hadn't considered that.  I've used Cygwin before and didn't have all that much trouble with it, surprisingly, but that was many years ago when I was trying to get into OS development for giggles.  I only ever used some assembler with it, but I'm sure g++ works fine in it.  Although I did want to use Visual Studio's IDE since I'm so used to it, and I have no idea how you'd set that up if it's even possible.  There's also the matter of generating Windows binaries with Cygwin... somehow...

I did consider installing a Linux VM or something for this purpose, but then I realized it was kind of stupid to have to install an entire OS just to compile something, and that if I was going to have to work inside of a VM and run my executables in there, I should probably reconsider what I was doing anyway.

-snip-

Yep, that's exactly the sort of nonsense I'm talking about.  I'm still groaning at the thought of trying to get V8 to compile on Windows again and am not likely to ever try it again.  I had to reinstall Windows and Visual Studio on this computer, so it's a newer version and I'm absolutely positive that the weird makefile maker (seriously?) that I have to use to build the VS project won't work.

[Gatleos]

I really don't know much about C#. Is it as portable as Java, and did they really fix any of the horrendous design choices in that language?

Honestly I'd just stick to Python for general application development if I could, but I had to get all anal about the seconds-long execution of a terrain generation function. Which was reduced to milliseconds when ported over to C++.

[frostshotgg]

I despise Java far more than I despise C++, if that's any consolation. Not only do you have to wade through endless stupid libraries to find what you need like in C++, but you also have to use a system that reserves all the resources it needs from the start while doing it! So what if it's using 30kb of the 1gb it's reserved, it's going to hog it all anyways!

[Skyrunner]

C# is pretty awesome. I don't know how cross platform it is, but it has all the features of a higher level language (no extra libraries needed for stuff 80% of the time, it's all in the std lib, and GC is cool), with the syntax of C++, without the cruft of Java.


But manually handling memory when you really need to -- I needed to deallocate a huge bitmap to put another into memory, but the GC didn't cooperate--along with handling raw data quickly is kinda awkward. You need to tag functions with unsafe for C#.

I'm sad that my familiarity with c++ is going to be useless later in life

[Mephisto]

C# is pretty awesome. I don't know how cross platform it is...

Depends. For the majority of cases, Mono is fine.

Unless you're doing a web app and at least pretending to do MVC. In which case... not at all.

[Orange Wizard]

Cython is pretty neat. It converts Python code into that of C, allowing for much faster execution. Not as good as well-written C, but being Python it's much faster to write.