** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD **
07-22-2012
, 06:46 PM
07-22-2012
, 09:56 PM
Quote:
I'm pretty sure you're out of luck in Java. In C# you can still write unmanaged code and allows you some access to actual pointers and such... but its really inconvenient.
Concurrent programming is where its at. As CPU clock speeds are quickly tapering off, the answer is more and more parallelism. More cores and wider registers.
I dont have any 1st hand experience with GOAL, but I have a friend who worked at Naughty Dog during the last of the "lisp years" and he always spoke very highly of it. From how it was described to me, it was particularly well suited to dealing with the challenges of developing on PS1/2 (which is something I do have 1st hand experience with): streaming and packing stuff in/out of a very small amount of RAM.
I think the main reason they didnt carry it on to PS3 development is that the guys who had created it in the first place had left the company. With them gone, I dont think anyone else really understood it well enough to want to gamble on moving it to the PS3.
Plus, there was a huge difference in the quality of the Sony development tools between the PS3 and PS2 and especially the PS1. So I dont think it felt like there was going to be as big a payoff by "going cowboy" with the dev tools. The state of PS1 tools was so weak, deciding to write your own compiler in a "non-standard" language was a little bit less of a stretch than it might seem today. (Dont get me wrong, I still think its jaw-dropping 31337
)
Even though the PS3's "cell" processor was pretty non-standard in a lot of ways... it was still based on PowerPC and had all the weight and experience of Motorola/IBM behind it... so there was going to be tons of good documentation (in English even!) and good compilers for sure. Working on the PS2 in the early days was like trying to develop for something you pulled out of a crashed UFO.
But I digress...
I dont think there's any real technical reason that stops Lisp, or any language that compiles down to native machine code, from being as fast as C. The real difference is that C compilers just have had so much more development effort behind them for so many years... they're very sophisticated at this point.
That said, it might be important to remember that C was developed to be a "slightly easier than assembly" way of programming. The C syntax was designed to enable the programmer to use the same design patterns as s/he would when using assembly. And given that processors today still have the same basic architecture of processors when C was first developed (stack-based, procedural), C-like languages might still have a kind of natural edge.
This is exactly whats happening already... OpenMP, OpenCL, CUDA, C++11... these all, in one way or another, have a focus on concurrency and they all compile to native machine code.
The difficulty of actually achieving a program that can scale across a multiple (and possibly variable) number of cores largely depends on problem at hand.
From my own experience, getting a program like SnG Solver to scale from 2 to 16 or even 1000 cores (on a GPU) has been relatively easy because the "work" is very homogeneous. Unlike say, Call of Duty on the PC. Even though the primary platform for CoD was the Xbox360 with its 3 cores, we pretty much hit a wall after 4 hyper-threaded cores. At the end of the day we were bottle-necked by the direct3d driver layer.
Concurrent programming is where its at. As CPU clock speeds are quickly tapering off, the answer is more and more parallelism. More cores and wider registers.
I dont have any 1st hand experience with GOAL, but I have a friend who worked at Naughty Dog during the last of the "lisp years" and he always spoke very highly of it. From how it was described to me, it was particularly well suited to dealing with the challenges of developing on PS1/2 (which is something I do have 1st hand experience with): streaming and packing stuff in/out of a very small amount of RAM.
I think the main reason they didnt carry it on to PS3 development is that the guys who had created it in the first place had left the company. With them gone, I dont think anyone else really understood it well enough to want to gamble on moving it to the PS3.
Plus, there was a huge difference in the quality of the Sony development tools between the PS3 and PS2 and especially the PS1. So I dont think it felt like there was going to be as big a payoff by "going cowboy" with the dev tools. The state of PS1 tools was so weak, deciding to write your own compiler in a "non-standard" language was a little bit less of a stretch than it might seem today. (Dont get me wrong, I still think its jaw-dropping 31337
)Even though the PS3's "cell" processor was pretty non-standard in a lot of ways... it was still based on PowerPC and had all the weight and experience of Motorola/IBM behind it... so there was going to be tons of good documentation (in English even!) and good compilers for sure. Working on the PS2 in the early days was like trying to develop for something you pulled out of a crashed UFO.
But I digress...
I dont think there's any real technical reason that stops Lisp, or any language that compiles down to native machine code, from being as fast as C. The real difference is that C compilers just have had so much more development effort behind them for so many years... they're very sophisticated at this point.
That said, it might be important to remember that C was developed to be a "slightly easier than assembly" way of programming. The C syntax was designed to enable the programmer to use the same design patterns as s/he would when using assembly. And given that processors today still have the same basic architecture of processors when C was first developed (stack-based, procedural), C-like languages might still have a kind of natural edge.
This is exactly whats happening already... OpenMP, OpenCL, CUDA, C++11... these all, in one way or another, have a focus on concurrency and they all compile to native machine code.
The difficulty of actually achieving a program that can scale across a multiple (and possibly variable) number of cores largely depends on problem at hand.
From my own experience, getting a program like SnG Solver to scale from 2 to 16 or even 1000 cores (on a GPU) has been relatively easy because the "work" is very homogeneous. Unlike say, Call of Duty on the PC. Even though the primary platform for CoD was the Xbox360 with its 3 cores, we pretty much hit a wall after 4 hyper-threaded cores. At the end of the day we were bottle-necked by the direct3d driver layer.
I was beating around the Clojure bush on those questions, as I'm starting to dive into the language. I just didn't think that it was for love of Lisp (completely) that the creator of this language created it as a Lisp. I was thinking that the reason is that the Lisps are able to represent concurrency easier than most other pre-packaged languages that don't have concurrency, multi-threading, and actor models built-in. As much as it's neat to build a language from the ground-up, the success of concurrency depends a lot on widespread adaptation, and that is why Clojure compiles to JVM, and for good or bad, I think that this is a step in the right direction. It now compiles to JVM, CLR, javaScript (Closure, actually), and yeah: Scheme to C, so it's only a matter of time before it compiles directly to C. There's a new project, only 20 days old on github now.
As for the other languages you list, they seem to be hardware-specific outside of C++11, but I think that it's all interesting stuff right now. Definitely an exciting time to study computer programming. What do you think the future will be? All C-based for the next 30 years before something else pops?
07-23-2012
, 07:12 PM
Quote:
With the usb 3.0 and thunderbolt connectivity on the RD MBP I think you can get external storage cheaper than internal storage if you need it. I can't speak to RAM requirements, I like the 8 in the base line model better than the 4 in my work machine. Processor wise you're probably correct, it's probably not worth the cost.
The screen is really, really nice, even for just reading text on.
The screen is really, really nice, even for just reading text on.
I will definitely notice 16 GB of RAM. I'll fill all 16.
It's hard for me to tell if the screen is something that looks cool in the store and that purists really like but I won't care about or something that I'll legitimately enjoy.
Do you notice the issues that MrWooster pointed out?
1) Thanks.
2) God ****ing dammit.
A lot of reviews say it really does get like 6 or 7 hours, though. Are you doing something that's somehow really battery intensive? Also, maybe you have a lemon that should be replaced?
Now I guess I'm leaning pretty heavily to the vanilla MBP. My ideal laptop just got fatter and lost 8 MB of RAM
. God ****ing dammit.
07-23-2012
, 07:26 PM
Quote:
Yeah.. 512 GB SSD is plenty for me. Even 256 GB will probably be fine. It's not like I have 512 GB databases to query, and I'm already in the habit of keeping lots of stuff on an external.
I will definitely notice 16 GB of RAM. I'll fill all 16.
It's hard for me to tell if the screen is something that looks cool in the store and that purists really like but I won't care about or something that I'll legitimately enjoy.
Do you notice the issues that MrWooster pointed out?
I repeat:
1) Thanks.
2) God ****ing dammit.
A lot of reviews say it really does get like 6 or 7 hours, though. Are you doing something that's somehow really battery intensive? Also, maybe you have a lemon that should be replaced?
Now I guess I'm leaning pretty heavily to the vanilla MBP. My ideal laptop just got fatter and lost 8 MB of RAM. God ****ing dammit.
I will definitely notice 16 GB of RAM. I'll fill all 16.
It's hard for me to tell if the screen is something that looks cool in the store and that purists really like but I won't care about or something that I'll legitimately enjoy.
Do you notice the issues that MrWooster pointed out?
I repeat:
1) Thanks.
2) God ****ing dammit.
A lot of reviews say it really does get like 6 or 7 hours, though. Are you doing something that's somehow really battery intensive? Also, maybe you have a lemon that should be replaced?
Now I guess I'm leaning pretty heavily to the vanilla MBP. My ideal laptop just got fatter and lost 8 MB of RAM
. God ****ing dammit.
Oh, I'm hoping the new OS will help with how crappy Chrome looks, it has noticeably softer text than Safari or Mail.