- How much is your life worth? - 4 Updates
- What do people think about std::multimap? - 1 Update
- Best way to use enum with classes - 9 Updates
- Preprocessor conditionals and size of type - 6 Updates
- libcxx <memory>, pointer_traits - 1 Update
- libcxx <memory>, pointer_traits - 1 Update
| "Chris M. Thomasson" <invalid@invalid.invalid>: Oct 19 03:37PM -0700 On 10/18/2016 5:49 PM, Rick C. Hodgin wrote: > I'm sorry it seems that way, Chris. I am trying to teach you the things > you'll never learn in this world, and won't even learn at many churches > because Satan is not just in the world, he's also in the church. [...] Rick, it is probably not a good idea to show up at a party, and starting telling people that it does not matter if they are a good person, for they are going to burn in hell forever unless they, get on their knees, and worship God. Also, telling them that its their fault as sinners for all of the problems on this planet, is not a good idea. Then telling them that its not a sin to make a lot of money, or getting married is to tempting for sin is in you, is so wrong. Also, you would end up telling them that the Earth is only a few thousand years old. Jesus Christ Rick, what the hell is wrong with you!!! God Damn It! Then you tell me: >> You sure fight with us! ;^o > I'm sorry it seems that way, Chris. WTF Rick! You are sick. SICK!!!!! WOW! You call people sinners, then act like you are not starting a conflict/fight. Total moron! |
| "Chris M. Thomasson" <invalid@invalid.invalid>: Oct 19 03:41PM -0700 On 10/19/2016 3:37 PM, Chris M. Thomasson wrote: > On 10/18/2016 5:49 PM, Rick C. Hodgin wrote: [...] > Then telling > them that its not a sin to make a lot of money, or getting married is to Well, unfortunately this is a typo. I wrote that Rick would say that its not a sin to make $$$ and marry. Well, I am wrong here... Rick says it IS a sin to make and keep profits, and a bad idea to marry because it has too much of a temptation to not worship God enough. [...] |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 19 03:54PM -0700 Chris M. Thomasson wrote: > Well, I am wrong here... Rick says it IS a sin to make and keep > profits, and a bad idea to marry because it has too much of a > temptation to not worship God enough. Read what I wrote again. Your comments regarding my position are wrong. Best regards, Rick C. Hodgin |
| "Chris M. Thomasson" <invalid@invalid.invalid>: Oct 19 04:02PM -0700 On 10/19/2016 3:54 PM, Rick C. Hodgin wrote: >> profits, and a bad idea to marry because it has too much of a >> temptation to not worship God enough. > Read what I wrote again. You wrote that Paul suggested against marriage because one might be too tempted by their spouse, and not worship God full time, or enough. Blah. > Your comments regarding my position > are wrong. You wrote that its a sin to make more money that the cost of labor via selling copies of software and keeping profits from sales beyond the cost of labor. You also mentioned that we should may employees via unexpected gifts. I can show you links if you want. You wrote this trash Rick. Damn it! |
| Daniel <danielaparker@gmail.com>: Oct 19 03:30PM -0700 Would you use it? Or would you more likely use std::map with a sequence mapped_type? Thanks, Daniel |
| Jerry Stuckle <jstucklex@attglobal.net>: Oct 19 10:48AM -0400 On 10/19/2016 4:12 AM, David Brown wrote: > /simultaneously/ read the next block from the next drive, and so on. > This all collects in memory and can be sent out on the network at > ridiculously high speeds. I know how RAID works. All versions of RAID, in fact. But unlike you, I know its limitations. Simultaneous reading is a nice idea - but you can't have two disks accessing the same memory at the same time. The best you can do is concurrent reading, with interleaved DMA - which, if nothing else is going on, cuts the speed in half. And don't even try to claim fancy busses which allow that to occur. > the link, you get only 150 MB/s sustained throughput. With four via a > port multiplexer, you get closer to 600 MB/s - each disk reads at 150 > MB/s to its cache, then transfers at 600 MB/s for a quarter of the time. Ah, but you just claimed that SDD drives are super fast and can be accessed as fast as memory can. Now you're trying to bring physical disks back into the discussion to "prove your point". Which is it? -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: Oct 19 10:49AM -0400 On 10/19/2016 4:12 AM, Christian Gollwitzer wrote: >> so on. > Ever heard of such novel concepts as RAID? > Christian Sure. Do you know the restrictions of RAID? -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: Oct 19 10:51AM -0400 On 10/19/2016 8:26 AM, Scott Lurndal wrote: > Actually, no, they don't. You lack an understanding of both the > protocols on the 6Gbit/sec SATA links and you lack an understanding > how processor chips transfer data internally. No, I understand how they work. But a few posts ago you were talking about SSDs and how fast they are. Now you're trying to go back to physical disks. Which is it? >> up the bit rate. > They allow full utilization of the 6Gbit/sec SATA lanes, which one > rust drive cannot (albeit high-end SSD's can come close). Sure, but we were talking about SSDs. Now you're trying to change the subject again? -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: Oct 19 10:52AM -0400 On 10/19/2016 5:02 AM, Ian Collins wrote: >> Too lazy to look it up yourself, I see. It's clear you don't care about >> what others claim. You're just bent on proving me wrong, aren't you? > Well now, you made the claim, so it's up to you to back it up. Nope, I didn't make the claim. Someone else made it here in this thread. You can find it - if you're intelligent enough to read, that is. Obviously you aren't. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| scott@slp53.sl.home (Scott Lurndal): Oct 19 03:05PM >As well as bus performance, and unless you're using DMA, cpu >performance. If you are using DMA, there are other limitations such as >bus contention. What bus are you talking about? Xeons have not had an FSB for a decade or more. Some processors use dual rings in the uncore, some processors have non-blocking crossbars, and with the advent of PCI-Express, the concept of a physical PCI bus no longer exists. Processor designers at Intel ensure that the internal pathways are sized and clocked sufficiently to handle the I/O capabilities built-in to the processor. http://www.anandtech.com/show/8423/intel-xeon-e5-version-3-up-to-18-haswell-ep-cores-/4 |
| Ian Collins <ian-news@hotmail.com>: Oct 16 02:12PM +1300 On 10/16/16 03:38 AM, Öö Tiib wrote: >> That's exactly what you're doing when you have to write code from >> scratch with every project. > Yes and I do not see where I suggested that. The joke of it is the arse doesn't realise agile development practices (especially XP) naturally produce reusable code. You do have to remember that jerryworld is stuck somewhere in the 90s. -- Ian |
| Ian Collins <ian-news@hotmail.com>: Oct 20 07:56AM +1300 On 10/20/16 03:51 AM, Jerry Stuckle wrote: > No, I understand how they work. But a few posts ago you were talking > about SSDs and how fast they are. Now you're trying to go back to > physical disks. Which is it? In this context, irrelevant. You are simply attempting to divert attention from your lack of understanding of storage and processor technology. >> rust drive cannot (albeit high-end SSD's can come close). > Sure, but we were talking about SSDs. Now you're trying to change the > subject again? No, he isn't. It doesn't matter what type of SAS device you use with a port multiplier, the behaviour remains the same. -- Ian |
| Jerry Stuckle <jstucklex@attglobal.net>: Oct 19 04:54PM -0400 On 10/19/2016 11:05 AM, Scott Lurndal wrote: > are sized and clocked sufficiently to handle the I/O capabilities > built-in to the processor. > http://www.anandtech.com/show/8423/intel-xeon-e5-version-3-up-to-18-haswell-ep-cores-/4 However you do it, you still have both address and data buses. They are required to get data to and from memory, and do have limitations. And sure, they handle the I/O capabilities built into the processor - but we're not dealing with just the processor here. In fact, if the card is using DMA, the processor isn't even involved. So the fact the "internal pathways" as you call them - they are still buses - will handle I/O capabilities built into the processor is completely immaterial. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: Oct 19 04:56PM -0400 On 10/19/2016 2:56 PM, Ian Collins wrote: > In this context, irrelevant. You are simply attempting to divert > attention from your lack of understanding of storage and processor > technology. Completely relevant - to anyone but you. But then you have a history of changing your tune when challenged and proven wrong. >> subject again? > No, he isn't. It doesn't matter what type of SAS device you use with a > port multiplier, the behaviour remains the same. Right. Keep dreaming. And you claim to know something about hardware? With that statement you just proved your ignorance. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Juha Nieminen <nospam@thanks.invalid>: Oct 19 04:22PM For a project I'm developing, I would want to conditionally compile something depending on whether unsigned long is (at least) 64-bit or not. And this has to be done in a manner that allows the code to be compiled with a C++98 compiler. 100% standard C++ compliance as well, obviously. The sizeof operator cannot be used in preprocessor macro conditionals, so that's not a working solution. The next approach I considered is to use ULONG_MAX from <climits>, which is perfectly C++98-compatible. The problem with this, however, and unlike one could perhaps hastily think, is how to actually check if ULONG_MAX is a 64-bit value or not. You see, if the compiler doesn't actually support 64-bit integers, specifying one in the preprocessor conditional probably won't work (so you probably can't just do a ULONG_MAX >= 0xFFFFFFFFFFFFFFFFUL). I suppose that you could do a #if ULONG_MAX > 0xFFFFFFFFUL and it might probably work (if it's larger than 32 bits, it's practically certainly 64-bit), but somehow it doesn't feel completely right. Is there a proper way of doing this? --- news://freenews.netfront.net/ - complaints: news@netfront.net --- |
| Marcel Mueller <news.5.maazl@spamgourmet.org>: Oct 19 06:49PM +0200 On 19.10.16 18.22, Juha Nieminen wrote: > as well, obviously. > The sizeof operator cannot be used in preprocessor macro conditionals, > so that's not a working solution. Some compilers support this, but the standard does not require the preprocessor to be aware of language features. AFAIK newer standards allow more at this point. > which is perfectly C++98-compatible. The problem with this, however, > and unlike one could perhaps hastily think, is how to actually check > if ULONG_MAX is a 64-bit value or not. (ULONG_MAX & 0xffffffffL) != ULONG_MAX ? Of course, it wont tell you how many bits ULONG_MAX actually has. But you may cascade several of this conditions and execute the ones with more bits only if the condition before is true to avoid overflows in integer constants. > You see, if the compiler doesn't actually support 64-bit integers, > specifying one in the preprocessor conditional probably won't work > (so you probably can't just do a ULONG_MAX >= 0xFFFFFFFFFFFFFFFFUL). It probably won't compile on pure 32 bit platforms. (integer constant out of range) > Is there a proper way of doing this? I found nothing better, even at stackoverflow. But do you really need the size of long? Or is it more constructive to use int64_t or something like that where 64 bits are required. In fact not every 64 bit platform have 64 bit for long int (although this is likely). You may need long long int in this case. And some 64 bit platforms use 64 bit even for int. AFAIR DEC Alpha was one of them, because the Alpha 64 could not access 32 bit int reasonably fast. Marcel |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Oct 19 07:56PM +0200 On 19.10.2016 18:22, Juha Nieminen wrote: > which is perfectly C++98-compatible. The problem with this, however, > and unlike one could perhaps hastily think, is how to actually check > if ULONG_MAX is a 64-bit value or not. (ULONG_MAX >> 32) != 0 > practically certainly 64-bit), but somehow it doesn't feel completely > right. > Is there a proper way of doing this? I think the most proper way is to factor this code out as different headers, and let the compiler's include path take care of including the right one for the compiler at hand. If not that, then let the compiler invocation define a macro as 0 or 1, and require that macro symbol. Only if neither of these solutions are acceptable, consider the simple checking shown earlier, e.g., [code] #include <limits.h> #define HAS_BIG_LONG ((ULONG_MAX >> 32) != 0) #if HAS_BIG_LONG char const s[] = "Oooh, big long!"; #else char const s[] = "No big long :-("; 
Subscribe to:
Post Comments (Atom)
|
No comments:
Post a Comment