Movius
Guest
|
![](https://forums.tigsource.com/Themes/tigsource/images/post/xx.gif) |
« Reply #60 on: October 18, 2009, 07:49:21 AM » |
|
Question. How many of you taking a "strong position" in here are employed in IT as programmers/software engineers/whatever?
Note, these people do not count as 'employed in IT as programmers/software engineers/whatever': university students, open sauce lunix project co-ordinators/contributors and the like, those working at an educational institution, video game designers who once altered a lua script so that a traffic light in level 3 started as red instead of green.
|
|
|
Logged
|
|
|
|
increpare
Guest
|
![](https://forums.tigsource.com/Themes/tigsource/images/post/xx.gif) |
« Reply #61 on: October 18, 2009, 08:14:32 AM » |
|
Boris: Hmm. I'm out of my depth by this stage. Regarding D, this thread seems to give an approach: Like the C++ Blitz++ library, expression templates are used to convert vector expressions into efficient element-wise operations. Unlike that library, however, there is no reliance on the compiler's optimiser. Instead, the expression template is manipulated as text, converted into postfix, and then passed to a simple CTFE compile-time assembler, which creates highly efficient asm code which is used as a mixin. it's a very different approach to the C++ one. Mm. It's "abstract library" code so it rarely concern us who are user of this code. The advanced material regularly bleeds out of these libraries in the form of error messages (and, unfortunately, there's no end to this situation in sight). (some libs in boost are complex because they solve problems in complex domains)
Which libraries do you have in mind? I regularly get tripped up on the lambda-related boost libraries. Spirit I have a total love-hate relationship with. I love it, but I hate it. Compiler-generation is a complex domain, but spirit is, in my hands anyway, so utterly fragile. Compare this to many other specialized parser generators, where I don't find myself tearing my hair out when I put a comma in the wrong place.
|
|
« Last Edit: October 18, 2009, 08:19:31 AM by increpare »
|
Logged
|
|
|
|
Average Software
|
![](https://forums.tigsource.com/Themes/tigsource/images/post/xx.gif) |
« Reply #62 on: October 18, 2009, 08:14:51 AM » |
|
And not only will it correctly do vector maths, it'll build an expression tree, determine the best way to evaluate it (there are lots of matrix optimizations), and then inline all the code to do it as if it were a single function that you'd written ahead of time. AFAIK, no other language can do that. Some languages may have operator overloading, but they don't have the template power to do that, nor implicit casting that makes the whole process opaque to the user. Ada can do it. Most of C++'s operator overloading concepts came from Ada.
|
|
|
Logged
|
![](http://www.averagesoftware.org/images/fsf.png) What would John Carmack do?
|
|
|
increpare
Guest
|
![](https://forums.tigsource.com/Themes/tigsource/images/post/xx.gif) |
« Reply #63 on: October 18, 2009, 08:25:37 AM » |
|
Ada can do it. Most of C++'s operator overloading concepts came from Ada.
Reading this right now. (edit: link fixed)
|
|
« Last Edit: October 18, 2009, 08:29:34 AM by increpare »
|
Logged
|
|
|
|
Klaim
|
![](https://forums.tigsource.com/Themes/tigsource/images/post/xx.gif) |
« Reply #64 on: October 18, 2009, 08:36:10 AM » |
|
The advanced material regularly bleeds out of these libraries in the form of error messages (and, unfortunately, there's no end to this situation in sight). Right, that's one of the big problems the Commitee is working on, so at least they are working on solving that. (That's good to know that most of the compiler software developers are in the Commitee...) Which libraries do you have in mind? I regularly get tripped up on the lambda-related boost libraries. Spirit I have a total love-hate relationship with. I love it, but I hate it. Compiler-generation is a complex domain, but spirit is, in my hands anyway, so utterly fragile. Compare this to many other specialized parser generators, where I don't find myself tearing my hair out when I put a comma in the wrong place. I was thinking about more domain specific stuff like Boost.Graph. It's easy to understand what is a graph but not to understand domain specific concepts that are more maths oriented that are required to understand how to use boost graph right. That's the same for some other libraries. Maybe Boost.Random too as it allows more specific random algorithms than the usual rand function. Nothing really hard in the end, but it's logical that you have to understand the domain before understanding the tool that you'll use to solve a problem in this domain. Using Ogre without understanding the graphic pipeline is problematic. Question. How many of you taking a "strong position" in here are employed in IT as programmers/software engineers/whatever? I've worked as profesionnal programmer in several domains(commercial, stock management, games), languages (C++,python,lua,C#,java,add anything useful for the task here) and plaforms (embedded, phones, consoles) for 6 years now (argh already 6...). I've worked 2.5 years in a game company on NDS games and now I work on flash/flex/as3 based games on the client side and java/groovy on the server side. I work at home on games since I was in school and started c++ since high school. Since then I use mostly use C++ and other langauges for tools and scripting for my home projects. I don't know exactly how much my advice is useful. And my position is not "strong". In fact, if you have a "strong" position, most of the time you didn't even tried to see the two extremes of the same concept. It's better to learn following first an extreme way of doing things, then to extreme opposite. That gives you insights about what to do in the real world.
|
|
« Last Edit: October 18, 2009, 08:39:50 AM by Klaim »
|
Logged
|
|
|
|
increpare
Guest
|
![](https://forums.tigsource.com/Themes/tigsource/images/post/xx.gif) |
« Reply #65 on: October 18, 2009, 09:08:53 AM » |
|
Right, that's one of the big problems the Commitee is working on, so at least they are working on solving that. It's probably many many years off now that concepts've been ditched from 0x. (also yeah that ada paper ends up with a system a lot more verbose than what would allow for simple expressions alla c++).
|
|
|
Logged
|
|
|
|
Alex May
...is probably drunk right now.
Level 10
hen hao wan
|
![](https://forums.tigsource.com/Themes/tigsource/images/post/xx.gif) |
« Reply #66 on: October 18, 2009, 09:29:05 AM » |
|
Question. How many of you taking a "strong position" in here are employed in IT as programmers/software engineers/whatever?
Note, these people do not count as 'employed in IT as programmers/software engineers/whatever': university students, open sauce lunix project co-ordinators/contributors and the like, those working at an educational institution, video game designers who once altered a lua script so that a traffic light in level 3 started as red instead of green.
i
|
|
|
Logged
|
|
|
|
Klaim
|
![](https://forums.tigsource.com/Themes/tigsource/images/post/xx.gif) |
« Reply #67 on: October 18, 2009, 09:32:35 AM » |
|
Right, that's one of the big problems the Commitee is working on, so at least they are working on solving that. It's probably many many years off now that concepts've been ditched from 0x. (also yeah that ada paper ends up with a system a lot more verbose than what would allow for simple expressions alla c++). Yeah, I hope for some implementations to spawn in gcc and msvc to help getting it faster :/
|
|
|
Logged
|
|
|
|
increpare
Guest
|
![](https://forums.tigsource.com/Themes/tigsource/images/post/xx.gif) |
« Reply #68 on: October 18, 2009, 09:37:43 AM » |
|
Yeah, I hope for some implementations to spawn in gcc and msvc to help getting it faster :/
yessssssssss ![Smiley](https://forums.tigsource.com/Smileys/derek/smiley.gif)
|
|
|
Logged
|
|
|
|
Average Software
|
![](https://forums.tigsource.com/Themes/tigsource/images/post/xx.gif) |
« Reply #69 on: October 18, 2009, 11:54:58 AM » |
|
Right, that's one of the big problems the Commitee is working on, so at least they are working on solving that. It's probably many many years off now that concepts've been ditched from 0x. (also yeah that ada paper ends up with a system a lot more verbose than what would allow for simple expressions alla c++). Yeah, it ain't pretty, but it can be done. Considering that Ada has language level support for threading, things like matrix multiplication might perform better in parallel, something like this: function "*" (M1, M2: Matrix) return Matrix is Result: Matrix(M1.Rows, M2.Columns);
task type Multiply is entry Go(Row, Column: in Natural); end Multiply;
task body Multiply is begin accept Go(Row, Column: in Natural) do -- Do the math, putting the results in Result. end Go; end Multiply;
Sub_Tasks: array (1 .. Result.Rows, 1 .. Result.Columns) of Multiply; begin -- Start all the sub-tasks. for X in Sub_Tasks'Range(1) loop for Y in Sub_Tasks'Range(2) loop Sub_Tasks(X, Y).Go(X, Y); end loop; end loop;
return Result; end "*"; Language level threading supporting (instead of lame library based support) is something I'd really like to see in C++. Alas, it will never be so.
|
|
|
Logged
|
![](http://www.averagesoftware.org/images/fsf.png) What would John Carmack do?
|
|
|
bateleur
|
![](https://forums.tigsource.com/Themes/tigsource/images/post/xx.gif) |
« Reply #70 on: October 18, 2009, 01:08:15 PM » |
|
Language level threading supporting (instead of lame library based support) is something I'd really like to see in C++. Alas, it will never be so. Be careful what you wish for. Threads themselves are arguably a terrible, terrible idea. Parallelism is great, but threads may not be the best way to achieve it. (I say "may not" because I have no better proposal, not because threads are somehow acceptable.) Programmers have been trying to find good ways to efficiently code parallel programs for decades. So far: very little progress.
|
|
|
Logged
|
|
|
|
Klaim
|
![](https://forums.tigsource.com/Themes/tigsource/images/post/xx.gif) |
« Reply #71 on: October 18, 2009, 01:19:53 PM » |
|
Well there seem to be some ideas like data driven tasks model that allow to easily organize all your code in parallel but the only limits are some libs you use that might become bottleneck if they dont provide a way to use your task scheduler. More about that in this discussion on the ogre forum.
|
|
|
Logged
|
|
|
|
Glaiel-Gamer
Guest
|
![](https://forums.tigsource.com/Themes/tigsource/images/post/xx.gif) |
« Reply #72 on: October 18, 2009, 01:21:21 PM » |
|
Programmers have been trying to find good ways to efficiently code parallel programs for decades. So far: very little progress.
While threads are cool and all, I always thought there was some overhead in setting up a thread (to the extent that doing one matrix multiplication over 3 threads would actually be a waste of time and resources). I keep wondering myself if parallelism could be brought into compiler-level optimization. I.e, marking sections of code as independent of each other, then on the small scale executing blocks in parallel. (gonna write in psuedo code syntax instead of compiled assembley) int a=1, b=2, c=3, d=4, e=5; a+=b*c; c=a*b; e=d*b; e++; d+=e; a+=d;
the compiler could break it up into 1: int a=1;
2: int b=2;
3: int c=3;
4: int d=4;
5: int e=5;
//wait for 1, 2, 3 6: a+=b*c; c=a*b;
//wait for 4, 5 7: e=d*b; e++; d+=e;
//wait for 6,7 8: a+=d;
then, besides the waits, each block could be executed in parallel instead of each line waiting for the previous to finish that's my idea on how parallelism should work. Threads on the high level, then the compiler doing this junk to our code on the low level
|
|
|
Logged
|
|
|
|
iggie
|
![](https://forums.tigsource.com/Themes/tigsource/images/post/xx.gif) |
« Reply #73 on: October 18, 2009, 02:03:38 PM » |
|
Question. How many of you taking a "strong position" in here are employed in IT as programmers/software engineers/whatever? Ouch, IT is a dirty word in my mind. I work as a software engineer in a tech + games company as a day job, our IT guy just dusts the server and replaces routers! There must be a reason all console + the majority of PC gaming uses C++, it is fast and scales well to large teams of programmers. I have nothing against any other language for hobby, web, business or scientific purposes - indeed it is fun to learn several - but nothing beats C++ in the games industry. Now on the other hand, it is a painful and frustrating language to learn, work with, and debug. It will eat up less able programmers and will punish smart coders endlessly. It is very hard to dip into as you need a lot of code just to start a tiny game - it is a fair commitment to get into, but the end results are well worth it... eventually.
|
|
|
Logged
|
|
|
|
BorisTheBrave
|
![](https://forums.tigsource.com/Themes/tigsource/images/post/xx.gif) |
« Reply #74 on: October 18, 2009, 02:23:37 PM » |
|
Glaiel-Gamer: Processors work like like that internally, except the parallism is optimistic, rather than blocking. It's why assembler optimization is now essentially impossible to do manually - you have to consider what instructions that processor might be doing at the same time, and ensure that you don't queue give it ones that cause it to give up on the parallel approach. I.e. a well placed NOP can make the program faster, as it means one instruction won't request a value before it's been computed.
|
|
|
Logged
|
|
|
|
mcc
|
![](https://forums.tigsource.com/Themes/tigsource/images/post/xx.gif) |
« Reply #75 on: October 18, 2009, 06:35:59 PM » |
|
Veering a little offtopic but... Glaiel, have you ever heard of Cilk? It is actually surprisingly similar to what you propose there. Like here is a Cilk program: cilk int fib (int n) { if (n < 2) return n; else { int x, y; x = spawn fib (n-1); y = spawn fib (n-2); sync; return (x+y); } } Every time you say "spawn", you could potentially be opening into a new thread while execution continues; when you say "sync" execution waits until all spawned work has finished. A "microscheduler" maintains threads of its own and assigns spawned work to threads in an optimal manner (or on a single processor system might just run everything serially). I don't believe it has the sort of notion where you can say something like "sync a" separately from "sync b", but I think you could actually emulate that by carefully putting the calculation of a and b in separate functions, then spawning each. It all seems really natural and one neat thing about it is that since they define this by just adding a couple of extra syntactic ideas to C, if you #define "spawn" and "sync" as noops Cilk code magically transforms into C.Unfortunately I've never really given it a shot... I actually learned about this from the ICFP (a Cilk team won one year), which actually Glaiel you especially might be interested in given your stated interest in Ocaml and such things. The early years of the ICFP especially were a great showcase for bizarro research languages.
|
|
|
Logged
|
|
|
|
Average Software
|
![](https://forums.tigsource.com/Themes/tigsource/images/post/xx.gif) |
« Reply #76 on: October 18, 2009, 07:32:26 PM » |
|
Language level threading supporting (instead of lame library based support) is something I'd really like to see in C++. Alas, it will never be so. Be careful what you wish for. Threads themselves are arguably a terrible, terrible idea. Parallelism is great, but threads may not be the best way to achieve it. (I say "may not" because I have no better proposal, not because threads are somehow acceptable.) I probably shouldn't have said "threads." What Ada tasks actually are is implementation defined. GCC happens to use threads (as I believe most Ada compilers do), but they could just as easily be processes or some new exotic form of matter.
|
|
|
Logged
|
![](http://www.averagesoftware.org/images/fsf.png) What would John Carmack do?
|
|
|
Glaiel-Gamer
Guest
|
![](https://forums.tigsource.com/Themes/tigsource/images/post/xx.gif) |
« Reply #77 on: October 18, 2009, 08:10:04 PM » |
|
I actually learned about this from the ICFP (a Cilk team won one year), which actually Glaiel you especially might be interested in given your stated interest in Ocaml and such things. The early years of the ICFP especially were a great showcase for bizarro research languages. I don't even know what Ocaml is But ya like, it'd be nicer if the compiler could do that kinda stuff for you
|
|
|
Logged
|
|
|
|
mcc
|
![](https://forums.tigsource.com/Themes/tigsource/images/post/xx.gif) |
« Reply #78 on: October 18, 2009, 08:41:06 PM » |
|
I don't even know what Ocaml is
Yeah... I am stupid and briefly got you and increpare mixed up ![](http://platformers.net/forum/Smileys/default/psyduck.gif) ...Increpare, you may find it interesting to check out the ICFP!
|
|
|
Logged
|
|
|
|
increpare
Guest
|
![](https://forums.tigsource.com/Themes/tigsource/images/post/xx.gif) |
« Reply #79 on: October 19, 2009, 12:59:55 AM » |
|
will check it out ![Smiley](https://forums.tigsource.com/Smileys/derek/smiley.gif) The problem with automatically parallelizing code is that 1: you have to be sure that the functions being parallelized won't interfere with eachother (in C++ this is hard to do, in other languages this is easier) 2: you have to figure out what's good to parallelize (this is a hard problem, and one haskell, say, leaves to the programmer) Parallelizing annotations exist in grand central dispatch for Snow Leopard (and a couple of other concurrency libraries I think?), where they're apparently very fun to use.
|
|
|
Logged
|
|
|
|
|