Hi, anyone using the new processor?
Just wondering when/if Blitz will support fully.
Jim
Just wondering when/if Blitz will support fully.
Jim
Intel i7 and Blitz
Miscellaneous Forums/General Discussion/Intel i7 and Blitz It's working on all three versions available now, including the extreme version. I see no reason why it should not work. i7 executes all instructions of previous Intel processors, so it's kind of logical that Blitz will work. BlitzPlus and BlitzMax are also working.
Barney
Barney
It won't make any difference, the OS matters, the chip does not, Blitz will not use any of the new features of course.
Darkheart
Darkheart
Sorry, what I meant was will blitz use the 4 cores or just the one.
Jim
Jim
As far as B3D, B+ is concerned I'm pretty sure these are single core only, not sure about BMax.
Darkheart
Darkheart
Blitzmax (and BLIde, by the way) supports multi threading, so it would beneffit from the cores when creating multi-threaded applications. the threaded version of BlitzMax is on the SVN version only at the moment, the thread module comes with a great TThread class that works like a charm.
Sounds good!
What is the SVN version?
Jim
What is the SVN version?
Jim
What is the SVN version?
*shakes head*
It's a perfectly reasnoble question so I'll answer it (or at least try to with my limited knowledge of BMax).
He's referring to the "development" version which you can download from Blitz Research's Subversion (a popular CVS) Site, rather than the "Offical" version. Access to the Subversion database is only available to purchases of BlitzMax which is the most recent iteration of the Blitz language.
Darkheart
He's referring to the "development" version which you can download from Blitz Research's Subversion (a popular CVS) Site, rather than the "Offical" version. Access to the Subversion database is only available to purchases of BlitzMax which is the most recent iteration of the Blitz language.
Darkheart
but keep in mind: BM will not run on multiple cores unless you program that into your app. No trivial task and I would say given you don't know what SVN is, skip the idea of multitasking, thats a few worlds above SVN complexity wise.
when using threads and mutex the wrong way you easily make your app a 0 core app because it locks itself infinitely.
when using threads and mutex the wrong way you easily make your app a 0 core app because it locks itself infinitely.
What Dreamora said. Anyway, it is a good idea to play with threads if you're learning how to code, but keep on mind that multithreaded apps can fail randomly if a particular issue concurs on two or more threads, so I would not release anything multithreaded untill you have lots and lots of experience and have tested it on several machines with different core technologies, for a long period of time.
If you don't know about threads or how to program with them or what to watch out for/consider, you can always learn. Most people here don't know how to deal with them, but it's not beyond the scope of what you can learn. I didn't know how to use them either so I experimented and researched.
One of the problems with threading is that there is, in my opinion, a clash between the hardware model and the software model. We have hardware with multiple cores, and each core can only run one sequence of program code at a time. Each core is essentially single-threaded - programs flow `forwards`, not sideways. Then you have many of these cores next to each other, sharing the same resources, which presents a lot of problems. Then you have software running on this hardware which is essentially single-threaded. Then you have to try to get your single threaded application to split itself up *manually* into multiple parallelizable parts, taking great care not to cause collisions between each part, to synchronize them all so that on the whole they're working towards a common goal, and you have to write that into the code yourself.
I think what would be better, and I think I heard of Intel or someone doing work on this, is to have the hardware automatically and dynamically distribute workload across the multiple cores in the same way that workload is pipelined within each core, so that you could be running single-threaded or multi-threaded apps and the hardware would do all the distribution work for you. Wherever a piece of program is not dependent on the previous piece of program, it can be moved to another core. Meanwhile you have to try to split up an inherently single-minded application into multiple fragments, in order to get multiple fragmented cores to run them in parallel, single-mindedly. It's pretty wacky.
But it works. ;-D
One of the problems with threading is that there is, in my opinion, a clash between the hardware model and the software model. We have hardware with multiple cores, and each core can only run one sequence of program code at a time. Each core is essentially single-threaded - programs flow `forwards`, not sideways. Then you have many of these cores next to each other, sharing the same resources, which presents a lot of problems. Then you have software running on this hardware which is essentially single-threaded. Then you have to try to get your single threaded application to split itself up *manually* into multiple parallelizable parts, taking great care not to cause collisions between each part, to synchronize them all so that on the whole they're working towards a common goal, and you have to write that into the code yourself.
I think what would be better, and I think I heard of Intel or someone doing work on this, is to have the hardware automatically and dynamically distribute workload across the multiple cores in the same way that workload is pipelined within each core, so that you could be running single-threaded or multi-threaded apps and the hardware would do all the distribution work for you. Wherever a piece of program is not dependent on the previous piece of program, it can be moved to another core. Meanwhile you have to try to split up an inherently single-minded application into multiple fragments, in order to get multiple fragmented cores to run them in parallel, single-mindedly. It's pretty wacky.
But it works. ;-D